At 09:42 AM 7/16/2002 -0700, Damien Neil wrote: >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?
Doing some research, it doesn't look like there is any such support for this type of thing with POSIX api. I was trying to stress that real async IO could do seeks/writes/reads in parallel to processing, and I thought you were confusing a callback/dispatch loop with this. Now it appears you weren't confusing anything. :) >Bundling reads and writes sounds like a job for a buffered I/O layer. You are probably right for most cases. I do know there are softwares that don't use a standard buffered layer, but still do large writes, either sequential or random. The former being multimedia apps, the latter being relational DB engines like Oracle. There is still advantage to providing a non-buffered, scatter/gather interface for less system call overhead, right? >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. I doubt they are on Windows. On Mac, your guess is better than mine, since you actually run one. I can't speak for Palm, my only embedded experience is Win CE. I didn't make the decision that we should support the OS async facilities, Dan did, but I agree with him. IO is very commonly platform specific, no big deal there. >This doesn't allow an event to interrupt the current thread of >control, of course. The most common way of having multiple Which isn't acceptable. >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). This is the most common, and robust way to do it in userland. Many OS vendors packages already implement async like this. Why can't we? No reason, except I would trust Sun's implementation more than mine if it were available, and would much rather design our code to use platform specific facilities if they _were_ available. >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. Maybe you can hit the high spots for me, I don't use Tcl. >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? Hmm. If we can reasonably expect threading to be available, I don't see why we can't design an abstraction layer for the async calls, and people can use the normal blocking/non-blocking calls if they choose, and even make use of callbacks, which we will have to implement in some sort of event loop/thread. Anyway, I've gotten over my head here. Originally I was quoting Dan's goals as for async. My personal experience is only in networking, and I've used two methods: 1) An event loop with select() and a dispatcher 2) A background thread 2 gives much better latency on incoming packets than 1 for a small number of connections; I know this for a fact, as I've implemented a multiplayer game engine with it. Now, if this applies to disk IO, databases, etc. I have no clue. Thanks for the very good comments, Damien, feel free to flesh out some initial design or maybe a list of pros/cons for the various methods, since you seem to have a good handle on things. -Melvin
