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@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.