Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Hi Gilles, >>>>> >>>>> I tend to think that xnselect_destroy should signal an event on the >>>>> dying fd instead of just clearing the binding. The task blocking on >>>>> select currently does not get a hint that the fd is dead and will block >>>>> on select until some other event arrives. That's unfortunately not >>>>> standard conforming. >>>> Ok. Got it, I was mixing xnselect_destroy and xnselector_destroy. Yes, >>>> right, something should be done. What is supposed to happen? Is it >>>> supposed to be signaled as an exceptional condition? >>>> >>> It should be signaled so that the caller tries to read/write/whatever >>> and then gets the information that the fd is down. >> Looks to me like you get a wakeup for nothing... From the spec: >> http://www.opengroup.org/onlinepubs/009695399/functions/select.html >> >> I do not see anything specified for the fds closure. > > "A descriptor shall be considered ready for reading when a call to an > input function with O_NONBLOCK clear would not block, whether or not the > function would transfer data successfully. (The function might return > data, an end-of-file indication, or an error other than one indicating > that it is blocked, and in each of these cases the descriptor shall be > considered ready for reading.)"
Ok. But I need to think a bit for a correct implementation. The naïve implementation would result in the closed fd being constantly signaled and select no longer blocking. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core