I don't understand what you are getting at with your discussion of Schedulers. Are these simply wrappers around threads?

What is Schedulers.io()? Is that a 'built-in type? A built-in function? You don't explain what it is or what it is doing. Similarly with AndroidSchedulers.mainThread().

Hi Mark,
Ivan might get into more detail on this later, but I think that you are getting a point here. We are discussing about describing a bit more of the inner workings of Rx in the early chapters, so that readers will not get confused with elements just being thrown at them without any specific context about what they do or why they are needed by the system. Some more detailed explanation about schedulers and how they can be implemented will be present at the very end of the book, but we think that some introduction might help a lot, possibly right after chapter 1. Stay tuned for an update on this topic!

Thanks for this. I agree that the details may not be appropriate this early in the book but I, for one, get sidetracked by these kinds of things since I can't really understand the intent without having some idea of what the pieces do.

I just went back and took a look at the discussion in the book on this and still don't understand the context of the example. You state that .subscribeOn executes every task or operator that’s placed before it in the chain on the specified Scheduler while .observeOn() executes every task or operator that’s placed after it in the chain on the specified Scheduler.

I don't understand why, in the example on page 32 you say it would crash. I assume that the listing is being run on the UI thread and the .subscribe is after the .subscribeOn call so it is not on the IO thread, bu still on the UI thread. So why does it crash?

Also, why is the .observeOn before the call to .subscribe?

I think another way of describing what my question here is that we have a call to auth(...) that returns an Observable<AuthResponse>. The call to subscribeOn is made on this returned object. So, how does subscribeOn execute a completed task - it has already returned a value - on a different thread?

Along the same lines, assuming the auth call was somehow moved to the IO thread, what does that say about the items in the chain after the subscribeOn call? What thread do they operate on (without any observeOn call)? The statement you made earlier is that subscribeOn affects all those items that appear before it in the chain, not after it. So this would put the auth call on the IO thread but not the subscribe call. So, why do we need the observeOn call?

And, to put the question into a larger context, I assume that the whole chain is invoked in a function that is being invoked on the UI thread. Otherwise the whole discussion of blocking the UI would be moot.

thanks for the feedback and the suggestions. I'm just not sure about the list...iterator passage you are mentioning on page 22. Is this the passage in page 20 perhaps?
survival games online

@547703, there have been at least 6 new versions of the book since my original question so I can't go back and see the original context of the question. In addition, I have a better understanding of schedulers than I did 2 years ago. I don't think I mentioned list/iterator as the question had to do with schedulers.