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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.