On Tue, Jul 22, 2003 at 11:41:25PM -0400, Dan Sugalski wrote:
> First, to get it out of the way, I don't have to convince you of
> anything. You have to convince me. For better or worse I'm
> responsible for the design and its ultimately my decision. If you
> don't want async IO, it's time to make a very, very good case.
I hope that I haven't given the impression that I feel otherwise.
You're the designer, and Parrot is your baby. I'm just expressing
my opinion; you are of course completely free to disagree with me.
Let me restate my position, since I think it's getting lost in the
general confusion:
I'd be happy if Parrot contained no support at all for interrupts,
in particular the traditional interrupt-based delivery of Unix
signals. I think that support for interrupts will come at a cost,
and I'd prefer not to have to pay that cost.
I've expounded at length in an earlier message on why I think
interrupts in application-level code is generally a bad idea. I
won't bother repeating myself here; I don't think I said anything
particularly controversial there.
I'm not arguing against non-blocking IO, event loops, a unified
event queue, or internally using the aio_*() API on Unix. I think
that all of these things are Nifty(tm) and I highly approve of all
of them.
I /am/ arguing against exposing the aio_*() API (or its equivalent)
to code running atop the Parrot VM, on the grounds that it uses
interrupts as a part of the API. I'd rather just have non-blocking
IO calls and a good event queue.
On a somewhat related note, I'm dubious about the performance gains
that code using interrupt-driven IO will see as opposed to code using
event-loop driven IO. I /think/ you're telling me that I'm wrong,
and that interrupt-driven IO does indeed have performance benefits;
it's possible that you're actually telling me that event-loop driven
code with non-blocking IO has performance benefits as compared to
threaded code with blocking IO. If it's the latter, then we are
in violent agreement. :>
- Damien
