Re: "write()" semantics



Hi George,

On 6/17/2011 12:31 PM, George Neuner wrote:
On Tue, 14 Jun 2011 10:20:30 -0700, Don Y<nowhere@xxxxxxxx> wrote:

But, imagine the last thing write() does before return-ing
is to OVERWRITE the contents of buffer[] with gobbledegook.
No, not "zero()". Nothing "predictable". In fact, it may
elect to overwrite buffer[] with exactly the original
contents of buffer[]! (!)

So, you, the application, KNOW that your data got (or will get)
written. You *know* that you can now freely scribble on buffer[].
*But*, I am telling you that you can't rely on:

holdme = buffer[0]
write(buffer)
ASSERT(buffer[0] == holdme)

[that's the essence of the question I pose]

That's not really a question. The semantics in this scenario are not
different from one in which the user is prevented from touching the
buffer. The fact that the user *might*, for an indeterminate time
during the write call, be able to use/modify the buffer as a
scratchpad is not relevant ... the user has no way to know when that
safe period is done and any modifications will be lost, so the overall
semantics are the same as if the user was prevented.

Argh! We're still thinking on different wavelengths :-/

Think of the above code snippet in a *synchronous* write().
I.e., the user would *know* that it is "safe to touch the buffer"
as soon as the write() returned (indeed, the user *can't* touch
the buffer once he has invoked write() because, in this case,
the write would BLOCK!).

In my *current* implementation, the ASSERT is not guaranteed!
I.e., write() could do anything it wanted to do to the contents
of the buffer. For the caller to expect the buffer's contents
to be unchanged (as the ASSERT implies) would be folly.

I maintain that this is different from what most write()
implementations are like. E.g., you could fill a buffer
with some data, call write() (blocking or otherwise) and
*expect* the contents of the buffer to be unchanged after
the call. I.e., its as if the contents were *copied* to
the "device" and the original remained intact, in place.

My (current) implementation doesn't provide the caller with
this guarantee -- regardless of blocking/nonblocking call.
This lets me optimize the write().

I contend that it doesn't *cost* the (typical) program
anything because, IME, you write() something and then
discard it in preparation for writing the *next* thing.

I am proposing adding that "implicit" behavior back in
to my write(). I.e., so that the buffer contents remain
intact *after* the write().

[It's not a question of a "race" between the "I/O system"
and the application]
.



Relevant Pages

  • Re: "write()" semantics
    ... is to OVERWRITE the contents of buffer[] with gobbledegook. ... elect to overwrite buffer[] with exactly the original ... For the caller to expect the buffer's contents ... call write(blocking or otherwise) and ...
    (comp.arch.embedded)
  • Re: "write()" semantics
    ... is to OVERWRITE the contents of buffer[] with gobbledegook. ... elect to overwrite buffer[] with exactly the original ... semantics are the same as if the user was prevented. ...
    (comp.arch.embedded)
  • Re: point to point confusion
    ... when to use what modes of both blocking and non blocking com? ... > Only if there is enough unused buffer space. ... > there is no buffer space for the message and a matching receive has not ...
    (comp.parallel.mpi)
  • Re: Integer to "string" conversions
    ... because of the win/win of not having to marshal data into a temporary buffer ... to buffer this out at the page size or twice the page size. ... the blocking problem was to use pthreads. ... socket routines, let me know - but I highly recommend writing your own first ...
    (comp.lang.c)
  • Re: Socket weirdness
    ... I have a much better understanding now of blocking/non-blocking Sends, BeginSend, ACK and RST, and TCP/IP in general. ... It depending what is going on (i.e. how full the send buffer is). ... | did not wait for ACK, even if it was the "Blocking" type. ...
    (microsoft.public.dotnet.framework)