At 11:18 AM 7/15/2002 -0700, Damien Neil wrote: >On Mon, Jul 15, 2002 at 12:16:29AM -0400, Melvin Smith wrote: > > 1) Async support. The IO system needs to be asynchronous and re-entrant > > at the core, whether by threads or by use of the platform's async support. > > Other things like callbacks assume other features of Parrot to be finished, > > like subs/methods. > >Out of curiosity, what's the motivation for supporting true signal-driven >async IO (which is what you seem to be referring to)? In my experience, >nonblocking IO and a standard event loop is more than sufficient, and >far easier to implement--especially portably.
Hi Damien, 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. 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. Finally, I'm not an async IO expert, so don't take anything I say too seriously. :) I'm just a product of all the hoopla that I read. I do know that each OS implements it differently, for example last time I checked Solaris did it with light-weight threads, whereas Digital UNIX/Tru64 (and maybe AIX??) did it with true kernel threads. 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'll try doing some research for some performance cases so maybe I can add to this discussion. -Melvin
