Email List: Xaustin-group-lX
[All Lists]

Re: non-blocking

To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: non-blocking
From: Andrew Josey <yyyyyy@xxxxxxxxxxxxxxxxx>
Date: Tue, 27 Mar 2001 08:24:55 +0100
References: <UTC200103262031.WAA25678.aeb@vlet.cwi.nl>
All,
This looks editorial, so I'd rather we tackle this now.
I've summarised the situation below:

The definition of Blocking is now in D5+:

A property of an open file description that causes it to wait for the
requested action to be performed before returning.


The D5 and D5+ definition of non-blocking is currently:

3.240 Non Blocking
A property of an open file description that causes it to either
perform the requested action or return an indication that the action
could not be immediately performed, in either case returning without
delay (other than normal scheduling delays) from the call.

Note:
The exact semantics are dependent on the type of file associated with
the open file. For data reads from devices such as ttys and FIFOs, a
successful return usually indicates that data sufficient to satisfy
the read was immediately available. Similarly, for writes, that space
to perform (at least part of) the write was available, and for networking
not to await protocol events (for example, acknowledgements) to occur.

The proposal circulated by Andries with one slight addition from me
in [++]:

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 requested action associated with+]
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.

I would then propose we make a minor change to
Blocking for consistency :

A property of an open file description that causes [+function calls
associated with+] it to wait for the requested action to be performed
before returning.


On Mar 26, 10:31pm in "RE: non-blocking", yyyyyyyyyyyyyyy@xxxxxx wrote:
> I suppose Andrew will determine proper procedure here.
> When d6 is prepared with your change, he can perhaps
> take my comments along, regarding them as editorial.
> (They are mostly intended editorially - the current text
> does not make sense and my text attempts to formulate
> what the author intended to say.)
> And otherwise this must perhaps be an aardvark for d6.
>


-----
Andrew Josey                                The Open Group
Austin Group Chair                          Apex Plaza,Forbury Road,
Email: yyyyyyy@xxxxxxxxxxxxx                Reading,Berks.RG1 1AX,England
Tel:   +44 118 9508311 ext 2250             Fax: +44 118 9500110

<Prev in Thread] Current Thread [Next in Thread>