If you move your mouse continually the query may not fail. Do not stop moving

I wonder if this is just feel-good nonsense for the user or if it's actually because moving the mouse causes the message loop to pump and thus prevents something or other from timing out...

nice way to say "it's not a bug, it's a feature".

Seems it's more about incorrect implementation of an event loop rather than a change in active processes. I assume the purpose of the screensaver is to save the screen, not to sleep other processes when it is activated. I further assume that hardware interrupts and event creation are the things happening while moving the mouse continuously. Based on these assumptions, I'm almost certain the screensaver isn't the problem.

This reminds me a bit of how networking works on OS X and iOS (at least if you are using the "standard APIs" the way they are supposed to be used: The networking that is going on is tied to a runloop. Some apps tie the networking stuff to the main run loop. You can see which apps do that by simply opening a context menu in the app somewhere or open a regular menu from the app's main menu. The run loops will be "halted" for as long the menu is open and thus your networking will stop. As soon you dismiss the menu the networking will continue.

At first this may seem totally bullshitty: Imagine a download manager. Do you really want the download to pause every time you open a context menu? Well it turns out it is not such a bad idea in many cases: What if the context menu allows you to cancel the download? If the download were to go on in the background you would have to explicitly take care of that. If you tie the networking callbacks to your main runloop this simply can't happen.

Of course there are also a lot of use cases where you want your networking code to not have anything to do with your main runloop...

This isn't really correct. Runloops have modes. Often networking happens in a mode that is not restricted (see NSRunLoopCommonModes here https://developer.apple.com/library/ios/documentation/cocoa/... ).

If you are running your network code in default mode on the main thread (problematic doing that and it's probably better to use async methods these days) then yes that can happen but it's usually programmer error.

On Mac, entering a modal window will usually put the runloop in a context that regular events won't fire and only those that mater to the modal window will fire. Commons mode almost always fires though.

I work on Apportable (YC2011) and we have reimplemented CFRunLoop/NSRunLoop down to the bare metal. A lot of misconceptions on how it works we find.