Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Jan Kiszka wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Ok for returning -EINTR, it is documented. Kernel-space is not so >>>>>> different from user-space, rt_task_unblock could wake-up a kernel-space >>>>>> task blocked in a call to rt_cond_wait. >>>>>> >>>>>> However, if the epilogue returns an error, we must return it. >>>>>> >>>>> OK for this. Pushed an update, but I also modified it further to avoid >>>>> returning without the mutex lock unless that one is also failing. Maybe >>>>> in-kernel POSIX requires the same fix, will check. >>>> Still not OK. You should reacquire the mutex only if the error is 0, >>>> -ETIMEDOUT or -EINTR. With any other error, we do not know if we can >>>> call the epilogue safely. >>> We _must_ reacquire the mutex - but, granted, we actually have to take >>> care of invalid cond objects. Lot's of bugs... >> No. If the error is another error than 0, -ETIMEDOUT, or -EINTR, it >> means that the error was detected prior to freeing the mutex. So, we do >> not have to re-acquire the mutex. Quoting POSIX: >> >> "Except in the case of [ETIMEDOUT], all these error checks shall act as >> if they were performed immediately at the beginning of processing for >> the function and shall cause an error return, in effect, prior to >> modifying the state of the mutex specified by mutex or the condition >> variable specified by cond." >> >> POSIX does not talk about -EINTR, because it states that in this case, >> we should return 0 to the application. > > OK, but EIDRM was missing in your list. Will adjust both patches.
No, EIDRM is part of the "other errors than ETIMEDOUT and 0" -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core