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?
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.)
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".)
JEff
