RE: Semantic Ambiguity in LSB

>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.
>
>This is only one of many examples. These kind of ambiguities are not  
>unexpected so we need to figure out how to deal with them.
>
>1) Does anyone else care? These are fairly subtle semantic issues  
>that does affect whether LSB-conformant implementations are truly  
>conformant and it directly affects application portability.
>
>2) Who should we ask if we come across this kind of issues? Is it lsb- 
>spec, lsb-test or some other mailing list like the kernel mailing list?

It depends.  In the cases where the LSB specification
intends to be a binary instantiation of the corresponding
POSIX interface, the discussion may need to reside there
(the Austin Group list or filing an aardvark (bugreport) there.
It's okay to ask on lsb-spec first to see if we agree.

Otherwise, lsb-spec if the specification is unclear or
imprecise; lsb-test being more a place for discussing the
tests we have or are developing - although there's no
harm in posting there too until someone objects.