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

[Trent Nelson]

On Thu, Oct 11, 2012 at 07:40:43AM -0700, Antoine Pitrou wrote:
> On Wed, 10 Oct 2012 20:55:23 -0400
> Trent Nelson <trent at snakebite.org> wrote:
> > 
> >     You could leverage this with kqueue and epoll; have similar threads
> >     set up to simply process I/O independent of the GIL, using the same
> >     facilities that would be used by IOCP-processing threads.
> 
> Would you really win anything by doing I/O in separate threads, while
> doing normal request processing in the main thread?

    If the I/O threads can run independent of the GIL, yes, definitely.
    The whole premise of IOCP is that the kernel takes care of waking
    one of your I/O handlers when data is ready.  IOCP allows that to
    happen completely independent of your application's event loop.

    It really is the best way to do I/O.  The Windows NT design team
    got it right from the start.  The AIX and Solaris implementations
    are semantically equivalent to Windows, without the benefit of
    automatic thread pool management (and a few other optimisations).

    On Linux and BSD, you could get similar functionality by spawning
    I/O threads that could also run independent of the GIL.  They would
    differ from the IOCP worker threads in the sense that they all have
    their own little event loops around epoll/kqueue+timeout.  i.e. they
    have to continually ask "is there anything to do with this set of
    fds", then process the results, then manage set synchronisation.

    IOCP threads, on the other hand, wait for completion of something
    that has already been requested.  The thread body implementation is
    significantly simpler, and no synchronisation primitives are needed.

> That said, the idea of a common API architected around async I/O,
> rather than non-blocking I/O, sounds interesting at least theoretically.

    It's the best way to do it.  There should really be a libevent-type
    library (libiocp?) that leverages IOCP where possible, and fakes it
    when not using a half-sync/half-async pattern with threads and epoll
    or kqueue on Linux and FreeBSD, falling back to processes and poll
    on everything else (NetBSD, OpenBSD and HP-UX (the former two not
    having robust-enough pthread implementations, the latter not having
    anything better than select or poll)).

    However, given that the best IOCP implementations are a) Windows by
    a huge margin, and then b) Solaris and AIX in equal, distant second
    place, I can't see that happening any time soon.

    (Trying to use IOCP in the reactor fashion described above for epoll
     and kqueue is far more limiting than having an IOCP-oriented API
     and faking it for platforms where native support isn't available.)

> Maybe all those outdated Snakebite Operating Systems are useful for
> something after all. ;-P

    All the operating systems are the latest version available!
    In addition, there's also a Solaris 9 and HP-UX 11iv2 box.
    The hardware, on the other hand... not so new in some cases.

        Trent.