On Fri, Jul 18, 2003 at 05:58:41PM -0400, Uri Guttman wrote:and event loop i/o doesn't usually support async file i/o. many people conflate the two. event i/o handles sockets, pipes and such but none support files. the issue is that the async file i/o api is so different (or non-existant) on all the platforms. dan wants to make clean async file i/o in the core by using a blocking thread on each i/o request and synchronizing them with this event queue in the main thread. it has the advantage of being easier to code and should work on most platforms which have threads. and he wants async file i/o in parrot core since it is faster and has to be in the core to be properly supported at higher levels.
Right, there are two independent issues here: Support for asynchronous IO (an OS feature distinct from non-blocking IO), and VM-level support for interrupts in Parrot. The latter is what I am questioning.
So we'll skip all the rest for the moment, and we can get into that if we need to.
We're supporting interrupts at the interpreter level because we must. It doesn't matter much whether we like them, or we think they're a good idea, the languages we target require them to be there. Perl 5, Perl 6, Python, and Ruby all have support for Unix signals in pretty much the way you'd get them if you were writing C code. (That is to say, broken by design, dangerous to use, and of far less utility than they seem on the surface)
It would be entirely possible for Parrot (or a Parrot library) to use AIO at a low level, without introducing interrupts to the VM layer.
Sure. But what'd be the point? Adding in interrupts allows a number of high-performance idioms that aren't available without them. They certainly won't be required, and most of the IO you'll see done will be entirely synchronous, since that's what most compilers will be spitting out. You don't *have* to use IO callbacks, you just can if you want to.
The fact that most event loops do not support async file IO on Unix systems is due to a combination of deficiencies in the Unix APIs (select() and poll() don't work on files), and lack implementation in the event library. There is certainly no reason a traditional event loop (such at Tcl's, which is an excellent example of a well-done event system) can't use AIO at a low level to support async file IO on Unix.
Yep, definitely. This is why there's the unified event system, so you can do async I/O on files, on sockets, handle window system events, interprocess messages and interthread messages with a single point of coordination.
Regarding AIO being faster: Beware premature optimization.
I'm going to start carrying a nerf bat around and smack people who trot this one out.
Ignoring the fact that you can often get a 2x or 3x improvement in throughput with async IO, the original quote referred to *implementation* optimization, and was generally referring to fun tricks like splitting data elements across the unused bits of other struct members, bizarre bitwise ops, and odd side-effects. (And at the time the quote came, hardware had a lot of odd side-effects which were fun to use)
While it's not inappropriate to apply it to design, we're nowhere near that point. This isn't premature optimization, or optimization of any sort--it's design, and it should be done now. This is what we're *supposed* to be doing. It's certainly reasonable to posit that async IO is a bad design choice (won't get you very far, but you can posit it :) but please don't trot out the "premature optimization" quote.
And are you referring to OS-level AIO (which often does have performance advantages), or application-level AIO using a collection of threads as you describe above (which I suspect will be slower than single-threaded non-blocking IO, owing to synchronization costs between threads)?
You may suspect, but you'd turn out to be incorrect--using threads to simulate a real async IO system still has performance wins. And we're going to be using native async stuff when we can.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
