On Tue, 2004-05-04 at 11:36, Dan Sugalski wrote:
> At 11:25 AM -0400 5/4/04, Aaron Sherman wrote:
> >So, all Parrot IO will be asynchronous? Does that mean that there's no
> >way to perform an atomic read or write?
>
> Yes, and there isn't now anywhere anyway so it's not a big deal.
I was speaking in terms of Parrot. Obviously, at the OS level some
writes are guaranteed atomic (e.g. POSIX dictates that writes of
PIPE_BUF or fewer bytes are atomic on a pipe, but that's neither here
nor there) and others are not. What I was asking was more in terms of
what could happen to Parrot while your write is in an unknown state.
Specifically, I'm concerned that I might want to say:
become immune to any events
perform write
re-sensitize to events
But, if writes are implemented using the event-handling system, won't
that mean that you can't actually do that? Here's one scenario for a
filter that I think demonstrates my concern:
read event handler:
perform synchronous write
This simple example might perform a partial write, then get a read event
and queue up a second write, perform a partial write on that, then queue
up a third write due to another event....
You can feel free to tell me there's some obvious way this is avoided,
as I admit I'm no expert in the domain of asynchronous IO management.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
