Gilles Chanteperdrix wrote: > 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
OK, with the definitions //#define USE_SIGXCPU //#define USE_EXPLICIT_SCHED #define CANCEL_TYPE PTHREAD_CANCEL_DEFERRED //#define CANCEL_TYPE PTHREAD_CANCEL_ASYNCHRONOUS #define USE_TEST_CANCEL I get on my ARM MX31ADS system: -bash-3.2# ./cancel-test Real-Time debugging started Segmentation fault The program behaves differently when running under gdb but the segmentation fault happens somewhere in pthread_cancel. It works better on my PowerPC TQM5200 system: -bash-3.2# ./cancel-test Real-Time debugging started ctrl_func: started at count 0 ctrl_func: sleeping for 2sec 500000000ns calc_func: counting till 50 calc_func: at count 0 calc_func: at count 1 calc_func: at count 2 calc_func: at count 3 calc_func: at count 4 calc_func: at count 5 calc_func: at count 6 calc_func: at count 7 calc_func: at count 8 calc_func: at count 9 calc_func: at count 10 calc_func: at count 11 calc_func: at count 12 calc_func: at count 13 calc_func: at count 14 calc_func: at count 15 calc_func: at count 16 calc_func: at count 17 calc_func: at count 18 calc_func: at count 19 calc_func: at count 20 calc_func: at count 21 calc_func: at count 22 ctrl_func: cancel at count 23 ctrl_func: stopped at count 23 main terminating in 2 seconds... But the messages from calc_func are display before the task gets actually canceled, which I do not understand. On ARM, it behaves similar if I disable explicit setting of the cancellation type: //#define USE_SIGXCPU //#define USE_EXPLICIT_SCHED //#define CANCEL_TYPE PTHREAD_CANCEL_DEFERRED //#define CANCEL_TYPE PTHREAD_CANCEL_ASYNCHRONOUS #define USE_TEST_CANCEL Enabling/disabling other options does not work as expected either, like using USE_EXPLICIT_SCHED. The cancellation does then not work any more. Wolfgang. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
