Wolfgang Grandegger wrote:
> Hi Gilles,
>
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>>>> Now, the question is, do you realistically plan to write an application
>>>>> which makes no syscall in its real-time loop?
>>>> Unlikely, but it may happen in case of programming errors. Anyhow, the
>>>> pthreads will run legacy code and it would be a pain to add
>>>> pthread_testcancel where necessary. But maybe there is a more elegant
>>>> and simple solution to do a defined exit/abort.
>>> In case of programming error, enable the xenomai watchdog, it will
>>> forcibly kill the problematic thread.
>> To give you a more complete answer: most blocking functions are
>> cancellation points in the PTHREAD_CANCEL_DEFERRED case, so, you
>> probably do not need to add pthread_testcancel at all. The only
>> exception is pthread_mutex_lock: this way, cancellation happens for well
>> defined mutex states, and you may install cleanup handlers with
>> pthread_cleanup_push/pthread_cleanup_pop if ever a thread may be
>> destroyed while holding a mutex. With PTHREAD_CANCEL_ASYNCHRONOUS, the
>> situation is not that clean.
>
> Well, there seems something wrong with it, also PTHREAD_CANCEL_DEFERRED
> with pthread_testcancel does not work reliably and consistently and it
> still behaves different on my ARM and PowerPC systems. I have attached
> my revised test program allowing to enable/disable various method of
> thread creation, setup and cancellation. They all work fine with the
> Linux POSIX libraries. With Xenomai, only a few work as expected on my
> ARM and PowerPC test systems.
Could you explain us exactly what happens ?
--
Gilles.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
