[Python-ideas] Async API: some code to review

[Guido van Rossum]

[Richard Oudkerk (?)]
>> > It is a common pattern to have multiple threads/processes trying to
>> > accept connections on an single listening socket, so it would be
>> > unfortunate to disallow that.

[Guido]
>> Ah, but that will work -- each thread has its own pollster, event loop and
>> scheduler and collection of tasks. And listening on a socket is a pretty special
>> case anyway -- I imagine we'd build a special API just for that purpose.

On Tue, Oct 30, 2012 at 9:05 AM, Kristján Valur Jónsson
<kristjan at ccpgames.com> wrote:
> I don't think he meant actual "threads" but rather thread in the context of coroutines.

(Yes, we figured that out already. :-)

> in StacklessIO (our custom sockets lib for stackless) multiple tasklets can have an "accept" pending on a socket, so that when multiple connections arrive, wakeup time is minimal.

What kind of time savings are we talking about? I imagine that the
accept() loop I put in tulip/echosvr.py is fast enough in terms of
response time (latency) -- throughput would seem the more important
measure (and I have no idea of this yet).
http://code.google.com/p/tulip/source/browse/echosvr.py#37

> We have also been careful to allow multiple operations on sockets, from different tasklets, although the same caveats apply as when multiple threads perform operations, i.e. no guarantees about it making any sense.  The important bit is that when such things happen, you get some defined result, rather than for example a tasklet being infinitely blocked.  Such errors are suprising and hard to debug.

That's a good point. It should either cause an immediate, clear
exception, or interleave the data without compromising integrity of
the scheduler or the app.

-- 
--Guido van Rossum (python.org/~guido)