[Python-3000] iostack and sock2

[Jason Lunz]

On Wed, Jun 07, 2006 at 01:20:02AM +1200, Greg Ewing wrote:
> It's not quite the same thing, anyway. What I had in mind was
> attaching the handler itself directly to the file descriptor, rather
> than going through a signal number. That way, different piece of code
> can use the mechanism independently on different file descriptors
> without having to coordinate over sharing a signal handler.

I imagine if one were going to do this, that would be hidden in the
stdlib. The OS gives you the primitive needed to implement it, but yes,
there would have to be some infrastructure attached to the signal
handler to look up the fd on each SIGIO and multiplex the event out to
that fd's registered handler.

>From the point of view of the code attaching the handler to the fd, that
would all be pretty transparent, though.

This all reminds me of something I've been wondering about - how do
people feel about beefing up the stdlib's support for os primitives?
There are plenty of things in the os module that are unix-only, but at
the same time I've had to code things myself in C (like file descriptor
passing over a unix socket, for example).

One of the things I like about python is that it doesn't take a
java-like approach of only exposing lowest-common-denominator OS
facilities. os.select() is a good example - it's far more useful on unix
than on Windows because of the platforms' respective implementations.
But precisely because of that, it strikes me that python ought to expose
the windows equivalent of nonblocking i/o and select/poll - i think
that's overlapped i/o? Something like win32all, iow, could have a place
in the standard distribution.

Jason