I will try to figure out a way to make this a small self contained test. However, my debugger shows a thread waiting in pthread_join() while the thread to be disposed is still in rt_queue_read().
PTHREAD_CANCEL_ASYNCHRONOUS is kind of dangerous. Why does rt_task_shadow() do this? It seems the better approach is to let cancellation be handled on the secondary domain side of things, and let the shadow stuff clean up on its own. If I use rt_task_shadow() do I need to use rt_task_delete()? 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. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
