On May 10, 2004, at 9:05 AM, Dan Sugalski wrote:
At 8:31 AM -0700 5/10/04, Jeff Clites wrote: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.
Reads and writes from sockets are almost always going to be partial (at the OS level)--a write will only fill up the kernel write buffer and return (only blocking if it can't write even one byte), and a read will only return what's in the read buffer in the kernel (only blocking if there's not even one byte there to read). It's completely commonplace--we don't want to throw an exception in these cases. We can certainly loop until we've written or read as much as requested, and throw an exception if something goes wrong there, but we shouldn't give people the impression that it's expected to be able to write several KB to a pipe or stream socket in a manner which is "atomic" at the OS level--that's just not how these entities work.
JEff
