Re: [lsb-spec] RE: Semantic Ambiguity in LSB

Hi Nick,

That is certainly a valid interpretation. The question is how to  
determine if this is the *right* interpretation? This is exactly what  
we need to do to nail down the semantics precisely.

Getting this right is important. When we have build a comprehensive  
test suite, it will, in conjunction with (English) prose description,  
become THE reference for all future LSB developers and application  
developers.

One of the strategic objective behind our testing technology (started  
10 years ago) was to be able to detected & isolated very subtle  
changes in semantics (functional behaviour) of interfaces of  
operating systems like Linux. The other objective was to be  
implementation independent (blackbox) once the reference semantics  
has been nailed because implementations changes every day (bug fixes,  
feature development).

The impact to the LSB are:

1) LSB developers cannot change the semantics without explicitly  
declaring they are changing the semantics e.g. updating the man  
pages, release notes AND notifying the downstream community that test  
case #1,244,567,890 regarding the blocking behaviour of file  
descriptors has been changed.

2) Linux application developers will be able to depend on a stable  
and predictable LSB interface across different distributions.

Point #1 may be controversial so I would like to raise that point  
earlier to bring it to everyone's attention.

Regards,
Spencer

On Jun 3, 2005, at 16:21, Nick Stoughton wrote:


>>> As an example, in file and socket descriptors, LSB specification  
>>> does
>>> not describe explicitly what should be the correct behaviour of an
>>> implementation if an application change blocking mode of a
>>> file descriptor while some other thread is blocking on the same
>>> descriptor. O_NONBLOCK flag can be modified by fcntl() function, but
>>> there is no explicit definition of correct behaviour
>>> concerning blocked threads.
>>>
>>> So should any already blocked thread be unblocked after that, or it
>>> should stay blocked? This affects how a test case should behave.
>>>
>>>
>>>
> My personal read on this particular problem, which is not an LSB but a
> POSIX issue, is that the POSIX standard clearly states (at least for
> "read()") on XSH page 1190 line 37207-37209 and line 37213-37214 that
> if, on entry to read, the thread finds O_NONBLOCK is not set (i.e. is
> clear), the thread shall block until a very specific event happens  
> (data
> becomes available). It does not include the event that some other  
> thread
> changed the O_NONBLOCK flag, and so the blocked thred should not wake
> up. [[you can read this text in html form at
> http://www.opengroup.org/onlinepubs/009695399/functions/read.html]]
>
> However, if you disagree, I am more than happy to raise this at the
> Austin Group on your behalf.
> -- 
> Nick Stoughton      USENIX/FSG Standards Liaison
> [email protected]     (510) 388 1413
>
>
>