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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
