I really like the look of that, but I'm not comfortable enough with context managers right now to really think through it.  I thought about adding a timeout, but I'm only threading CP connection stuff, which has built in timeouts (it'll raise an exception, which causes the exception handler to call back to the main loop).

I definitely don't think we want a thread lock in this case though, because the point is to be able to open up preferences and change a few settings without waiting for the first one to complete.

It'd be interesting to look into a more uniform gui-threading-thing though, but a bit tough.  In some places, we use one callback like "def callback(result, exception)", and in others we hand in a successful callback and a failure callback (which works very well when we're just using handle_gui_exception).  If we could consolidate these, we could use an abstract backbone like this, and avoid all network activity in the main loop.