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. It would be nice if somebody could test it
on a X86 system. Maybe there is still something wrong with my test program.
I'm also puzzled why pthread_setschedparam() does make a mode switch to
secondary mode (sometimes).

Wolfgang.