----- 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