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

[Ben Darnell]

On Thu, Oct 11, 2012 at 2:18 PM, Guido van Rossum <guido at python.org> wrote:
>> Re base reactor interface: drawing maximally from the lessons learned in
>> twisted, I think IReactorCore (start, stop, etc), IReactorTime (call later,
>> etc), asynchronous-looking name lookup, fd handling are the important parts.
>
> That actually sounds more concrete than I'd like a reactor interface
> to be. In the App Engine world, there is a definite need for a
> reactor, but it cannot talk about file descriptors at all -- all I/O
> is defined in terms of RPC operations which have their own (several
> layers of) async management but still need to be plugged in to user
> code that might want to benefit from other reactor functionality such
> as scheduling and placing a call at a certain moment in the future.

So are you thinking of something like
reactor.add_event_listener(event_type, event_params, func)?  One thing
to keep in mind is that file descriptors are somewhat special (at
least in a level-triggered event loop), because of the way the event
will keep firing until the socket buffer is drained or the event is
unregistered.  I'd be inclined to keep file descriptors in the
interface even if they just raise an error on app engine, since
they're fairly fundamental to the (unixy) event loop.  On the other
hand, I don't have any experience with event loops outside the
unix/network world so I don't know what other systems might need for
their event loops.

>
>> call_every can be implemented in terms of call_later on a separate object,
>> so I think it should be (eg twisted.internet.task.LoopingCall). One thing
>> that is apparently forgotten about is event loop integration. The prime way
>> of having two event loops cooperate is *NOT* "run both in parallel", it's
>> "have one call the other". Even though not all loops support this, I think
>> it's important to get this as part of the interface (raise an exception for
>> all I care if it doesn't work).
>
> This is definitely one of the things we ought to get right. My own
> thoughts are slightly (perhaps only cosmetically) different again:
> ideally each event loop would have a primitive operation to tell it to
> run for a little while, and then some other code could tie several
> event loops together.
>
> Possibly the primitive operation would be something like "block until
> either you've got one event ready, or until a certain time (possibly
> 0) has passed without any events, and then give us the events that are
> ready and a lower bound for when you might have more work to do" -- or
> maybe instead of returning the event(s) it could just call the
> associated callback (it might have to if it is part of a GUI library
> that has callbacks written in C/C++ for certain events like screen
> refreshes).


That doesn't work very well - while one loop is waiting for its
timeout, nothing can happen on the other event loop.  You have to
switch back and forth frequently to keep things responsive, which is
inefficient.  I'd rather give each event loop its own thread; you can
minimize the thread-synchronization concerns by picking one loop as
"primary" and having all the others just pass callbacks over to it
when their events fire.

-Ben


>
> Anyway, it would be good to have input from representatives from Wx,
> Qt, Twisted and Tornado to ensure that the *functionality* required is
> all there (never mind the exact signatures of the APIs needed to
> provide all that functionality).
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas