Damien Neil wrote:
[snip]
> Also, given that asynchronous IO is a fairly unpopular programming
> technique these days (non-blocking event-loop IO and blocking
> threaded IO are far more common), I would think long and hard before
> placing support for it as a core design goal of the VM. If there
> is a compelling reason to use AIO, the implementation may better
> be handled at a lower level than Parrot; even if Parrot itself does
> not support AIO at the opcode level, Parrot programs could still
> use it by calling down to a C library.
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).
If we make it a core part of parrot, it will become more popular, simply
because of parrot's availability.
> > It's not just signals, there's a lot of stuff that falls into this
> > category. We've got to deal with it, and deal with it properly, since
> > not dealing with it gets you an 80% solution.
>
> 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.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
