![](https://secure.gravatar.com/avatar/5947d19db094dcaf873c8b886a725d06.jpg?s=120&d=mm&r=g)
On Wed, Oct 10, 2012 at 9:56 AM, Mark Adam <dreamingforward@gmail.com> wrote:
On Tue, Oct 9, 2012 at 1:53 AM, Ben Darnell <ben@bendarnell.com> wrote:
On Mon, Oct 8, 2012 at 10:56 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Mark Adam wrote:
1) event handlers for the machine-program interface (ex. network I/O) 2) event handlers for the program-user interface (ex. mouse I/O)
While similar, my gut tell me they have to be handled in completely different way in order to preserve order (i.e. sanity).
They can't be *completely* different, because deep down there has to be a single event loop that can handle all kinds of asynchronous events.
There doesn't *have* to be - you could run a network event loop in one thread and a GUI event loop in another and pass control back and forth via methods like IOLoop.add_callback or Reactor.callFromThread.
No, this won't work. The key FAIL in that sentence is "...and pass control", because the O.S. has to be in charge of things that happen in user space. And everything in Python happens in user space. (hence my suggestion of creating a Python O.S.).
Letting the OS/GUI library have control of the UI thread is exactly the point I was making. Perhaps "pass control" was a little vague, but what I meant is that you'd have two threads, one for UI and one for networking. When you need to start a network operation from the UI thread you'd use IOLoop.add_callback() to pass a function to the network thread, and then when the network operation completes you'd use the analogous function from the UI library to send the response back and update the interface from the UI thread. -Ben