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
Well.... do you? Really? Because if the write blocks you'll find you can't get timeout signals and your GUI's become unresponsive.
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.
That's why you don't do that. (And it doesn't come up in the real world anyway) Reads and writes in general get handled with explicit requests with callback functions, though you can put a generic handler on a socket or something if you want to. Usually, though, the way to handle it is with a read request re-queueing the next read request, since that's simpler.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
