[Xenomai] occasional EBADF in select() in notifier.c

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Mon Apr 21 23:53:17 CEST 2014

On 04/21/2014 11:32 PM, Gilles Chanteperdrix wrote:
> On 04/21/2014 11:24 PM, Matthias Schneider wrote:
>> Still working on thread suspension in forge/mercury, I occasionally get a EBADF
>> of the select() call in notifier.c. I suspect that this is due to accessing a 
>> copy of the file descriptor list notifier_rset while one of the file descriptors 
>> is being closed. This seems to be due to concurrent access on the notifier_rset 
>> from notifier_sighandler() and notifier_destroy(). "notifier_lock" is held in 
>> notifier_lock(), but not when copying and invoking select in notifier_sighandler().
>> The EBADF leads to a "spurious notification" reporting and process termination -
>>  obviously, the thread suspension was not triggered.
>> I can think of several ways of addressing this issue but I am not sure about 
>> side effects:
>> a) hold the "notifier_lock" mutex between copying the descriptor list and calling select
>> b) repeating the select() call in the case of EBADF
>> Any ideas?
>> Anyway, why is the select call necessary, isnt the file descriptor signaled via 
>> siginfo->si_fd, too?
> I do not know this part of the code, but normally, when select is called
> for a closed descriptor, select will return with the descriptor
> readable, EOF is returned when reading the descriptor, which can then be
> closed. We had a bug report some time ago to implement this behaviour in
> xenomai posix skin (so for cobalt).

Obviously, if it is already closed, read will not return EOF, and there
is no need to close it again, I got all mixed up, sorry for the noise.



More information about the Xenomai mailing list