This example behaves as expected. There must be some issue with my main application causing a problem. I have the same model set up, but sometimes the thread won't cancel and instead waits forever in rt_queue_read().
I realize with async cancels, there is no reason for the call to pthread_testcancel(). I've solved the main app's problem by putting rt_task_set_mode(T_PRIMARY, 0, 0); before the call to rt_queue_read() which forces it into the secondary domain. However, this seems real strange to me... the problem happens about 50% of the time but becomes 100% if I put a printf() after rt_queue_read() returns. Again, the example works perfectly. Here's the code from the app with the issue and the "hack" to fix it: rt_task_set_mode(T_PRIMARY, 0, 0); pthread_testcancel(); //cancellation point r = rt_queue_read(&treatment_meas_queue, &meas, sizeof(meas), TM_INFINITE); rt_task_set_mode(T_PRIMARY, 0, 0); pthread_testcancel(); //cancellation point The timing of this thread (pthread, shadowed) is driven by the queue. It will drop to the secondary domain as needed. (Not realtime critical.) Steven > -----Original Message----- > From: Gilles Chanteperdrix [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 03, 2008 2:37 PM > To: Steven Seeger > Cc: [email protected] > Subject: Re: [Xenomai-help] rt_queue_read and pthread_cancel() > > Steven Seeger wrote: > > If I have a shadowed thread that was created with pthread_create() and > > rt_task_shadow() that calls rt_queue_read() with an infinite timeout, > is > > there any reason it would not receive a cancellation point? I have an > > intermittent lock in pthread_join() on that thread while it's blocked > in > > rt_queue_read(). I call pthread_cancel() on the thread first. I have > the > > rt_queue_read() call with a pthread_testcancel() before and after it. > > You do not need to call pthread_testcancel(): rt_task_shadow sets the > thread cancellation type to PTHREAD_CANCEL_ASYNCHRONOUS, which means > that pthread_cancel will send a signal to this thread to terminate > it. So, the reason for the deadlock is probably elsewhere. Could you > reduce your application to a small self-contained test which wouls show > us what you are observing ? > > -- > > > Gilles Chanteperdrix.
qt.c
Description: qt.c
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
