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.
>
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
