----- Ursprüngliche Mail -----
> Von: "Florian Bezdeka" <florian.bezd...@siemens.com>
> I can't say much about the alchemy skin. Never used that myself. Have
> you checked the history if such a change was / could be intentional?
> CCing Jan...

Well, an application that relies on rt_task_unblock() now no longer works
with Xenomai 3. It used to work with 2.6.

In 2019 this was briefly discussed:
https://www.mail-archive.com/xenomai@xenomai.org/msg15990.html

Finally I found some cycles to work on that.

With my changes at least the application works again and the tests
on the customer side pass.
 
> The following comments are more or less implementation details...
> 
>> To restore the functionality provide a new function,
>> pthread_mutex_lock_eintr_np().
>> It can get interrupted and will return EINTR to the caller.
>> 
>> Signed-off-by: Richard Weinberger <rich...@nod.at>
>> ---
>>  include/cobalt/pthread.h |  2 ++
>>  lib/alchemy/mutex.c      |  2 +-
>>  lib/cobalt/mutex.c       | 14 ++++++++++++--
>>  3 files changed, 15 insertions(+), 3 deletions(-)
>> 
>> diff --git a/include/cobalt/pthread.h b/include/cobalt/pthread.h
>> index 3e9bd47053bc..2994c2467219 100644
>> --- a/include/cobalt/pthread.h
>> +++ b/include/cobalt/pthread.h
>> @@ -62,6 +62,8 @@ COBALT_DECL(int, pthread_mutex_destroy(pthread_mutex_t
>> *mutex));
>>  
>>  COBALT_DECL(int, pthread_mutex_lock(pthread_mutex_t *mutex));
>>  
>> +COBALT_DECL(int, pthread_mutex_lock_eintr_np(pthread_mutex_t *mutex));
>> +
> 
> COBALT_DECL should only be necessary for functions that live in the
> libc namespace and that need to be "intercepted" / affected by wrapping
> at linker level.
> 
> Your function looks libcobalt specific and as such should probably not
> live in the pthread_mutex_ namespace and generating the wrappers seems
> unnecessary.

Ok!

[...]

>> +COBALT_IMPL(int, pthread_mutex_lock_eintr_np, (pthread_mutex_t *mutex))
>> +{
>> +    return __pthread_mutex_lock(mutex, true);
>> +}
> 
> Same as above. Looks libcobalt specific and the wrapping part seems
> unnecessary.

Ok.

Thanks,
//richard

Reply via email to