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