At 6:29 PM -0700 7/21/03, Damien Neil wrote: [Stuff I've snipped]
I was going to refute this point by point, but I was getting cranky and the responses were less than helpful. So let's start over.
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. (Trotting out tired and massively overused aphorisms isn't a good way to do that)
Now, that having been said, there are some things we *aren't* doing.
We're not executing parrot bytecode code at interrupt time. Interrupt handlers put events into parrot's event queue for processing later.
We're *not* forcing anyone to use async IO. I fully expect that 99% of the code emitted by compilers will be synchronous. That's fine. Having an async core doesn't in any way preclude synchronous IO.
We're not going to block on a file read or write. Ever. (Well, except when systems lie and say data's ready and it isn't and we block because we believe them) If we do we can't process signals, handle socket IO, process timer events, or handle GUI events.
Here's what we *are* doing.
We are going to do all I/O under the hood asynchronously. Completed async IO puts an event in the event queue.
We are going to have a single unified event queue. All IO, timer, signal, and UI events go in it. All of 'em. We aren't going to do any of this "we have N different places to look for data" nonsense, where N is greater than three.
Apps are never required to deal with anything asynchronously if they don't want. If you don't want signals, block them. The events for them won't get delivered, or will be delivered and discarded. Want to explicitly drain the queue only when your app wants it? Fine. You can do that too.
The event queue generally gets drained (unless otherwise blocked) when waiting for an event (if you've not made signals plain events), when waiting for an IO request to complete, or when you sit and explicitly drain the queue.
On some platforms this will mean we'll need to spawn off a thread for a filehandle, if the platform has no or really lousy native async facilities. Not great, but better than nothing, because even faking it this way has the potential for performance boosts. (Ignoring the potential speculative reads we might issue asynchronously ourselves)
I've written async IO code to good native async facilities, seen async code to native facilities that blow the doors off any synchronous code I've ever seen, and written fake async IO with threads. It all has a throughput win. Go hit google or citeseer if you want to find some.
Bottom line is that parrot's IO will be asynchronous, with most code using a synchronous interface on top of it. That code'll get the benefits of true base asynchrony (being responsive to events while waiting) without having to do anything explicitly asynchronous. Code that wants to take the next step can.
Layering a synchronous interface on an async core is simple, but layering an async interface on a sync core is not. Moreover, parrot code *can't* truly layer an async interface on a sync core, because that layering, for it to work properly, has to be done at the lower levels of the interpreter. Which is where we're going to do it there, and one of the reasons we're doing it in general.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
