On Fri, Jul 18, 2003 at 05:42:10PM -0400, Benjamin Goldberg wrote: > AIO is unpopular because it's not widely/portably supported, whereas > non-blocking event-loop IO is, (one generally does have either select or > poll), as is blocking threaded IO (even if the thread starting stuff may > need to be different on some platform, it's *mostly* portable).
I disagree; AIO is not widely/portably supported because it is unpopular. Threading (on Unix systems, at least) is a much newer concept than AIO, and yet it is now nigh-ubiquitous; any modern OS needs to have solid threading support to be taken seriously. Portable libraries wrapping system-specific thread models are common. The only reason this hasn't happened with AIO is lack of user demand. The problem with AIO is that it has all the synchronization pain of threading combined with the code flow complexity of an event-based IO system. There are certianly occasions when AIO may prove to be the best or most elegant solution to a problem, but in most cases there are other approaches which are substantially simpler for the programmer. > If we make it a core part of parrot, it will become more popular, simply > because of parrot's availability. I'd be interested in seeing specific examples of problems that will be solved by adding AIO support to the VM layer. How will this feature be used in real-world programs? > > Outside of signals and AIO, what requires async event dispatch? > > User events, as you pointed out above, are better handled through > > an explicit request for the next event. > > Inter-thread notification and timers? True, these *could* be considered > to be "user events", but IMHO, there are times when we want a "user > event" to have the same (high) priority as a system signal. I'd like a specific example (general pseudocode fine) of inter-thread notification implemented using interrupts that a) doesn't include any race conditions, and b) can't be written more clearly using non-interrupt based code. I think you're vastly underestimating the difficulty of writing interrupt-based code that doesn't include race conditions. Consider that Parrot itself has given up on trying to do this: internally, interrupts (signals) will simply result in an event being added to a queue for later processing. - Damien