Re: "write()" semantics
- From: Don Y <nowhere@xxxxxxxx>
- Date: Fri, 17 Jun 2011 12:45:39 -0700
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
ASSERT(buffer == 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]
- Re: "write()" semantics
- From: Arlet Ottens
- Re: "write()" semantics
- Prev by Date: Re: pulse counter using LPC1768 proving to very challenging
- Next by Date: Re: OT: Grrrr... Frigging Fyzics!
- Previous by thread: Re: "write()" semantics
- Next by thread: Re: "write()" semantics