On 07/26/2017 05:22 PM, Philippe Gerum wrote:
> On 07/11/2017 01:40 PM, Henning Schild wrote:
>> I am not sure i like what is happening there. Maybe we should just
>> allow rt_mutex_create to return whatever syncluster_addobj returns.
>> I just looked at the code and the pattern where any error from
>> syncluster_addobj is turned into an EEXIST is in several places.
>>
> 
> I'm not sure I like it either, that does not make any sense actually -
> it even hides the ENOMEM error, which would be just insane. I pushed a
> patch fixing the issue globally for all callers of syncluster_addobj(),
> updating the inline documentation in the same move.
> 
>> We have an application that creates shadow threads whenever the first
>> cobalt syscall returns -EPERM. You can argue whether that is a good
>> idea, but turning an -EPERM into something else is also not a good idea.
> 
> As I mentioned lately, I would recommend pthread_kill(pthread_self(), 0)
> as a more robust way for a thread to check this. Receiving ESRCH would
> mean that it has not been shadowed.
> 

To clarify, I'm suggesting to use pthread_kill() in the slow/error path
of your code to confirm that EPERM as received really means "not a
shadow", and not the result of a consistency check performed by the core
on the mutex object when the debug option is turned on.

-- 
Philippe.

_______________________________________________
Xenomai mailing list
[email protected]
https://xenomai.org/mailman/listinfo/xenomai

Reply via email to