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.
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.
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.
(I specifically refer to Unix above because many non-Unix systems
have perfectly good support for monitoring files in their equivalents
of select(). So do some Unixes, for that matter.)
Regarding AIO being faster: Beware premature optimization. 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)?
> that is a major win since no other system i (or dan) has heard of has
> portable async file i/o. and it will be integrated into the core event
> handling so you will be able to mix and match async socket, terminal (on
> unix at least) and file i/o with timers. this is what i want. :)
Do you want to use interrupt-based IO at the VM level, or do you
want an event system which will function cleanly on sockets,
terminals, and files?
- Damien
