> you can't do non-blocking i/o on files without aio_read type calls. but
> what dan is saying is that the api the interpreter uses internally will
> be an async one. it will either use native/POSIX aio calls or simulate
> that with sync calls and callbacks or possibly with threads.
>
That sounds too ideal to me. The problem with aio is many implmenetations
use sync io and thread.
If we completely rely on aio, then we will have sync io on top of aio on top
of thread+sync io. It is
huge waste of resource and performance.
Actually we lost more than that, atomicity. The Unix read/write/seek are
atomic operations. With
async implementation, we will lose it. It is huge impact on many people (at
least me), who are
relying on atomic operations instead of complicated file locking. The seek
position is also lost
with async io.
> DN> I'm being a bit pedantic here because I've been involved in heated
> DN> debates in the past, which were resolved when the two sides realized
> DN> that they were using different definitions of async I/O. :>
>
> pipe, socket and char device async i/o is different from file async
> i/o. with pipes you are told when your request will work and then you
> make it. with files you make the request and then get told when it was
> done. both use callbacks and can be integrated under one async api. this
> api is what parrot will see and a sync api will be layered on top of
> this.
>
> the async i/o will be tied to the event system for timeouts and safe
> signals and such.
>
The async io may not be available universally. I have terrible experience
with Win32 console stream.
Some special device stream may not behave well under async io.
Anyway, I don't any reason we have to choose one over the other. Can we just
support both? What
are we arguing for?
Hong
