On Mon, Jul 15, 2002 at 08:59:40PM -0400, Melvin Smith wrote:
> True async IO implementations allow other things besides just notifying
> the process when data is available. Things like predictive seeks, or
> bundling up multiple read/writes, etc. aren't doable with select/poll loops.
> And the aioread/aiowrite/listio, etc. are a POSIX standard now, so they
> should be reasonably available on most UNIXen.
I'm not familiar with "predictive seeks", and a quick google didn't
turn up anything relevant; can you give a quick explanation?
Bundling reads and writes sounds like a job for a buffered I/O layer.
Are the aio* calls available on Windows? On the Macintosh? (My OS X
system doesn't have a manpage for aioread, and man -k aio doesn't
turn up anything obvious.) How about PalmOS? While the POSIX standard
is a help, I think async I/O remains far less portable than the more
traditional alternatives.
> You are right, though, I blurred the concepts. Callbacks are good to have
> as well,
> for calling code blocks when data is available, and this might be done
> as an event loop, or a thread. However, the talks I've had with Dan always
> ended
> up in us deciding that calling an event loop between every op, or even
> every N ops wasn't what we wanted to do.
Certainly, calling an event loop between every op would be insane.
That's not the normal way of using one, however. Consider the
(excellent) Tcl event loop as an example: When a condition triggers
the loop, it invokes the appropriate callback which runs to completion
before returning control to the loop.
This doesn't allow an event to interrupt the current thread of
control, of course. The most common way of having multiple
concurrent threads is, however, exactly that--threads. Threads
can be used independently (the Java approach; all I/O is blocking)
or in conjunction with an event loop (the Macintosh OS X event loop
takes this approach).
I really recommend taking a look at the Tcl event loop and I/O system,
if you haven't already. It's a joy to work with, and one of the best
features of that language.
> For many things, synchronous IO is adequate, and faster, but for people
> that really want the aio interface, I'm not sure it is worth trying to fake
> it.
I'm sure that there are things async I/O is very good at, but I'm
not certain it makes sense to design Parrot's I/O system around them.
Might it not make more sense for async I/O to be available via an
alternate API?
- Damien
