Semantic Ambiguity in LSB

Good Afternoon,

As I mentioned in the May 17th conference call, I am acting on behalf  
of the Institute for System Programming (Russian Academy of Science -  
http://www.ispras.ru) in evaluating the viability of generating an  
automated test suite for LSB.

As one of the precursor activities, we do a functional interface  
analysis of the functional interfaces defined in the LSB in order to  
characterize the interface semantics very precisely. Our experience  
has been that this is an crucial step since it flushes out any  
vagueness in the interfaces.

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?

Regards,
Spencer Cheng