Advice wanted: asynch I/O on unix

Donn Cave donn at u.washington.edu
Tue Jul 24 13:06:54 EDT 2001


Quoth "Russell E. Owen" <owen at astrono.junkwashington.emu>:
...
| The main problem is going to be how to buffer data until it can be read. 
| the parallel port card has no buffering of its own. Hence the complex 
| process outlined above.
|
| I was hoping unix and/or Python had some nice way to "magically" connect 
| an unbuffered input device to a FIFO buffer and make it look like a 
| socket, so I could use select and/or aynchcore.

Yes and no, I guess.  I would expect the file descriptor to be
selectable, at least in principle though subject to implementation
details, but the point is you probably want a more leisurely
select schedule, which would require a kernel I/O buffer.
I can't say there is no way to get the kernel to buffer a normally
unbuffered device, but it would have to be a Solaris dependent feature.
If Solaris supports some kind of loadable kernel module, it might be
a fun project to see if it could be done generically.  Far from
simplifying life though.

| P.S. Any advice regarding using "aioread", etc. vs "aio_read", etc.? 
| This is on Solaris 8. "aio_read", etc. seems to be the standard Posix 
| way of doing asynch I/O. I have no idea where "aioread", etc. come from, 
| but it's what the existing C code uses. At first glance, the interface 
| to aio_read looks a bit better, but I'd hate to pick something that was 
| buggy or deprecated.

I bet aio_read is not any kind of POSIX, but I do find it documented
on Digital UNIX, and not aioread.  So that's one vote for aio_read
being the more standard non-standard function.  Neither is documented
on NetBSD.  Buggy or not is up to Sun.  For the Python module, I
think Modules/cStringIO.c would be a good reference for C type that
presents a file interface.

	Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list