Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> Jan Kiszka wrote: >>> Gilles Chanteperdrix wrote: >>>> Not being able to join a deleted task undermines seriously the utility >>>> of rt_task_join... What is it useful for, then? >>> See the doc: You join or delete, but not both. >> Looks to me like a workaround: you are not able to handle properly the >> life-cycle of an RT_TASK, so you changed the rules... is there really no >> other way? > > First of all, it turns a SEGV into a proper error code. Moreover, > rt_task_join now officially finalizes the object for native (it always > did technically!), as does pthread_join for POSIX. No rule changed, just > rule documentation and violation detection added. One may argue about > join after delete, but for what use case such a change of rt_task_delete > semantic?
rt_task_delete, pthread_cancel, pthread_detach are not synchronous, after one of these calls, you do not have any guarantee that the ressources attached to a thread are free for re-use. After pthread_join, you do. So, the question is what is more important, to have a way to wait for the ressources attached to a thread to be freed? Or to avoid segmentation faults in broken application? I do not generally mind segmentation faults in broken applications if we can not avoid them without breaking other applications. A segmentation fault is one of the simplest things to debug. However, I do not have a strong opinion on this, it is just an open question. More generally, I would like us to discuss once and for all about the semantic of the various calls and their effect on the RT_TASK duration, instead of changing this semantic every release and risk breaking non-broken applications (I mean, the one which do not segfault). -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core