Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : native: Rework handling of pthread carrier thread

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]