> -----Original Message----- > From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 03, 2008 11:49 PM > To: Steven Seeger > Cc: [email protected] > > Subject: RE: [Xenomai-help] rt_queue_read and pthread_cancel() > PTHREAD_CANCEL_ASYNCHRONOUS is the way glibc makes a blocking call a > cancellation point. And internally, the glibc uses a signal in this > case. When running with Xenomai, the signal sent upon pthread_cancel > will cause the target thread to switch to secondary mode and run its > clean-ups from there. So, the exit should be clean when using this > approach.
My understanding is that PTHREAD_CANCEL_ASYNCHRONOUS actually makes the thread cancel immediately, while DEFERRED makes it wait for a cancellation point. DEFERRED will also cause blocking calls to exit with -EINTR I believe it is. That's why you put pthread_testcancel() after blocking calls before proceeding. This is safer because you test for cancellation when you've released resources. (You can also use cleanup handlers, but that can get annoying.) > > Now about your problems, are you fiddling with signals ? Like blocking > them, or doing things in signal handlers ? I am not doing anything at all with signals except a single handler in the main thread which catches SIGINT. This allows it to cleanup cleanly when ctrl-C is pressed. Is that a problem? > I do not know about that. I would have expected rt_task_delete to work > with a task shadowed with rt_task_shadow. Especially since > rt_task_delete runs pthread_cancel under the hood. As I mentioned, calling rt_task_delete() caused problems. If a thread is in primary mode and a signal comes in, does it really cause a switch to secondary? What if I am blocked inside rt_queue_read() and the cancel comes in? Will the routine exit at this point? Perhaps I should change my example I sent (qt.c) and not have the writer thread send anything, and see if it still joins. I don't have access to the system right at the moment, though. Steven _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
