Async IO notes

[Dan Sugalski]

Since it's bound to come up, we might as well get this out of the way now.

While Parrot will do async IO, we are making ordering guarantees for
reads and writes (though reads and writes will be considered separate
and ordered separately). That is, if you issue two or more reads or
writes, they will be satisfied in order as far as Parrot is concerned.

Most of the OSes that do async IO do this for us, so it's not likely
to be an issue (and on OSes with no or really lousy async IO support
we'll be doing it all via threads ourselves anyway) but I figure it's
good to make sure people know what the guarantees are.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Jeff Clites]

On May 4, 2004, at 9:02 AM, Dan Sugalski wrote:

> While Parrot will do async IO, we are making ordering guarantees for
> reads and writes (though reads and writes will be considered separate
> and ordered separately). That is, if you issue two or more reads or
> writes, they will be satisfied in order as far as Parrot is concerned.
>
> Most of the OSes that do async IO do this for us, so it's not likely
> to be an issue (and on OSes with no or really lousy async IO support
> we'll be doing it all via threads ourselves anyway) but I figure it's
> good to make sure people know what the guarantees are.

Do you mean multiple operations on the same filehandle, or globally? If
globally, that would mean that a slow network would block writes to the
local filesystem....? Or is that how AIO normally works?

JEff

[Dan Sugalski]

At 4:25 PM -0700 5/4/04, Jeff Clites wrote:
>On May 4, 2004, at 9:02 AM, Dan Sugalski wrote:
>
>>While Parrot will do async IO, we are making ordering guarantees
>>for reads and writes (though reads and writes will be considered
>>separate and ordered separately). That is, if you issue two or more
>>reads or writes, they will be satisfied in order as far as Parrot
>>is concerned.
>>
>>Most of the OSes that do async IO do this for us, so it's not
>>likely to be an issue (and on OSes with no or really lousy async IO
>>support we'll be doing it all via threads ourselves anyway) but I
>>figure it's good to make sure people know what the guarantees are.
>
>Do you mean multiple operations on the same filehandle, or globally?

The same filehandle. Each handle is treated separately, so any sort
of synchronization between filehandles needs to be provided by the
program.