Re: "write()" semantics
- From: Tim Wescott <tim@xxxxxxxxxxxxxxxx>
- Date: Mon, 13 Jun 2011 17:29:25 -0700
On 06/13/2011 02:51 PM, Don Y wrote:
Hi,
[I have nothing at all like a POSIX API! :> ]
My "write()" semantics essentially say, "Once invoked,
you forfeit the contents of 'buffer[]' -- even in asynchronous
mode."
This makes it a lot easier for my OS to move data around
as *it* sees fit. And, imposes minimal constraints on the
caller.
In "write()"'s case, it just means you *use* the buffer[]
contents, if necessary, *before* "write()"-ing them!
But, this means I can't take advantage of true parallelism
and/or I/O device scheduling delays. E.g., I can't start
an async write, get things enqueued for processing, and
*then* do a few last minute things with buffer[].
There is some cost to adding this support -- though I think
I already have most of the mechanisms necessary to do so in place.
So, the question is, how do *you* use write() and the data it
is called upon to process? E.g., if the de rigeur form is:
while (ALWAYS) {
...
fill(buffer);
...
write(buffer, device, mode);
}
then you *don't* need this proposed functionality.
Well, if I read your semantics correctly and unwind that loop, I get
fill(buffer) // with stuff to write it
....
write(buffer, device, mode); // write it
....
fill(buffer) // Aw crap!!
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
.
- Follow-Ups:
- Re: "write()" semantics
- From: George Neuner
- Re: "write()" semantics
- From: Don Y
- Re: "write()" semantics
- References:
- "write()" semantics
- From: Don Y
- "write()" semantics
- Prev by Date: Re: OT: Grrrr... Frigging Fyzics!
- Next by Date: Re: "write()" semantics
- Previous by thread: "write()" semantics
- Next by thread: Re: "write()" semantics
- Index(es):
Relevant Pages
|