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. 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). Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core