On May 10, 2004, at 7:31 AM, Dan Sugalski wrote:
At 10:34 AM +0100 5/10/04, Tim Bunce wrote:On Sat, May 08, 2004 at 04:59:52PM -0700, Jeff Clites wrote: > On May 8, 2004, at 10:30 AM, Dan Sugalski wrote: > >(Note that, regardless of anything else, we do need to separate out>stream IO and record IO, both for layer filtering reasons and for pure >practicality as there still are some pure-record filehandles (UDP >sockets and such) even on a Unix system)
On Unix, record-oriented IO is specific to sockets only (not filehandles in general). Not sure what you mean by "layer filtering".
If I write to a filehandle for a file opened in append mode I want (to be able to make) that write still be atomic when it gets to the operating system (ie not broken up into multiple writes, or merged with previous data).
That's what "layer filtering" means?
Nope, that's somethign else instead.
Read and write requests will be defined as atomic unless explicitly overridden. (Though some filehandles will allow partial reads at least by default. I don't think any will allow fragmenting reads or writes, however)
I assume that's not the case if there is a buffering layer in place for the filehandle? (Since the point of write-buffering is to aggregate writes.)
Yes. If you put a buffer layer in place then you've explicitly overridden the atomic guarantees of the stream. :)
Also, of course, you can't guarantee that things are atomic at the OS level. That is, if I try to write a large amount of data to a socket, the OS will only take part of that data at a time. Parrot can keep trying, and not return until all the data is written, but it's not "atomic" at the OS level. (That is, it can complete partially and then fail, or other data can get sent in between the "chunks".)
There are two things here which need to be separated out.
Parrot will make atomic writes to the OS. If we guarantee that we will and we can't, well... the write throws an exception. (If a filehandle has lifted that guarantee then we won't, of course) So trying to write 10K to a UDP socket's going to fail and throw an exception. That's fine.
If the OS then fragments the write, that's not our problem, and there's not a whole lot we can do about that. It's likely OK, though, since it's what generally happens now, with most IO living behind buffers. (And apps that bypass the buffers for reliability will presumably know what to do to make that happen)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
