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

Reply via email to