I believe in chapter 10 the “before” argument to “RunLoop.current.run” in the dedicated thread writer should be “Date.distantFuture” instead of “Date.distantPast”.
With distantPast the CPU is always pegged at 80-90% since the thread never sleeps. With distantFuture the thread always sleeps waiting for a message.
@freak4pc Can you please help with this when you get a chance? Thank you - much appreciated! :]
Hey @jlubawy. We’ve fixed this issue in the 2nd edition of the book, coming soon.
Thanks for your feedback! 
So it’s been a long time… But I think this issue has come back to bite us in another way.
The original fix was to change .distantPast to .distantFuture, this was to prevent pegging the CPU at 70-80% usage. This is probably not an issue for most users if there is only a single thread being allocated for this, but once you introduce 5-6 like in my use case the CPU issue becomes a problem.
A new issue I found because of this “fix” was that now the Threads never seem to exit, because the check for “canceled” may never happen if waiting forever. I’d suggest another fix to change .distantFuture to .now + 30 (or some other appropriate amount of sleep time).
Sorry to resurrect an old thread but this code is still very useful, and it seems like at least a few people are using it: swift - Realm same thread for NotificationToken observe commitWrite(withoutNotifying: [token]) - Stack Overflow
@jlubawy Thank you for sharing this - much appreciated!