I had also filed an aardvark on this topic, from two other points of
view:
1) blocking and non-blocking are not described as antonyms in the D5
text,
although they should be (only one (non-blocking, based on the context
below) refers to file descriptors, if I remember correctly).
2) Neither should refer JUST to file descriptors, which I believe is the
reason
for the asymmetry; some realtime need fixed one so it was OK for
realtime as
well, but it didn't fix the other.
If I remember correctly, this did get fixed, so this change (which is
reasonable
except that it needs to not be JUST for file descriptors) needs to be
reconciled
with whatever the final approved change was. (I don't have notes, but
it may
have been "Accept" for whatever I wrote.)
Donn
-----Original Message-----
From: yyyyyyyyyyyyyyy@xxxxxx [mailto:yyyyyyyyyyyyyyy@xxxxxx]
Sent: Sunday, March 18, 2001 6:18 AM
To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: non-blocking
I noticed that the Non-Blocking section is rather badly worded.
Andries
@ Page 75 Line 2461 Section Non-Blocking Comment []
Problem:
The text says: "For data reads a successful return indicates that
sufficient
data was available. Similarly, for writes, that space was available,
and for networking not to await protocol events."
This can only be parsed as
"For networking, a successful return indicates not to await protocol
events."
and is plainly nonsense.
Another problem is the text "causes the file description to perform the
requested action", which also is plain nonsense.
Another problem is that "For data reads a successful return
indicates that data sufficient to satisfy the read was immediately
available"
is misleading - read() will return partial data.
Another problem is that disk I/O usually is not influenced by
O_NONBLOCK,
but still can take time more than "normal scheduling delay".
It is better not to give promises here.
Action:
Write something like
3.240 Non-Blocking
A property of an open file description that causes function calls
involving it to return without delay when it is detected that the
function call cannot be completed without unknown delay.
Note: The exact semantics are dependent on the type of file associated
with the open file description. For data reads from devices such as ttys
and FIFOs this property causes the read to return immediately when
no data was available. Similarly, for writes, it causes the call to
return immediately when the thread would otherwise be delayed in the
write operation, e.g. because no space was available. For networking
it causes functions not to await protocol events (for example,
acknowledgements) to occur. See also 2.10.7 on page 532.
|