[Python-ideas] asyncore: included batteries don't fit

Ben Darnell ben at bendarnell.com
Wed Oct 10 19:29:35 CEST 2012


On Wed, Oct 10, 2012 at 9:56 AM, Mark Adam <dreamingforward at gmail.com> wrote:
> On Tue, Oct 9, 2012 at 1:53 AM, Ben Darnell <ben at bendarnell.com> wrote:
>> On Mon, Oct 8, 2012 at 10:56 PM, Greg Ewing <greg.ewing at 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



More information about the Python-ideas mailing list