Steven Seeger wrote:
> 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.
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.
Now about your problems, are you fiddling with signals ? Like blocking
them, or doing things in signal handlers ?
>
> If I use rt_task_shadow() do I need to use rt_task_delete()?
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.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
