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"


Xenomai-core mailing list

Reply via email to