Jan Kiszka wrote: > Gilles Chanteperdrix wrote: >> 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). > > To pick up this issue again (in order to get my queue flushed): > > We basically have to decide about the question what rt_task_delete > invalidates and what impact this shall have on rt_task_join. It is > already documented that rt_task_delete invalidates (and releases) the > kernel-side resources of a RT_TASK. The question is what shall happen to > the not explicitly mentioned user-side resources (ie. the pthread - > where available). > > Option 1 is to decouple both and keep the user side of a joinable > RT_TASK alive until it is explicitly joined. Option 2 could be to > declare both parts invalid on rt_task_delete. Based on this decision, > the finalization logic of rt_task_delete and rt_task_join then needs to > be adjusted to deliver the right behavior, including proper error codes > instead of sporadic SEGV.
Relying on the contents of the RT_TASK structure to know the state of a task is bound to fail: the RT_TASK structure may be copied around, so changing the contents of the RT_TASK structure in rt_task_delete, to use that information later will only work if the same RT_TASK structure is used later. This is fragile. > > Do we expect applications to rely on this joinability after > rt_task_delete? If yes, we should make it official, document the > descriptor split and the fact that the descriptor cannot be looked up > anymore after deletion but has to be saved beforehand. > > Independently, we need to clarify that cross-process join is not > supported. Trying to do this ATM will result in a SEGV (something I > missed so far). This is a regression. At some point in the past, a NULL pthread_t opaque pointer was used to mean that the thread was living in a different process, and rt_task_delete would skip the pthread_cancel. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core