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:
>>>> GIT version control wrote:
>>>>> Module: xenomai-jki
>>>>> Branch: for-upstream
>>>>> Commit: 0352b068600bd4ef3172c8a42416badbcdad32ca
>>>>> URL:    http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=0352b068600bd4ef3172c8a42416badbcdad32ca
>>>>>
>>>>> Author: Jan Kiszka <jan.kiszka@domain.hid>
>>>>> Date:   Wed Apr 28 15:08:11 2010 +0200
>>>>>
>>>>> native: Rework handling of pthread carrier thread
>>>>>
>>>>> This patch improves two pitfalls of libnative's interaction with
>>>>> underlying pthreads:
>>>>>
>>>>> First, it tries to detect double deletions (cancellations or joinings)
>>>>> of pthreads and report them via an error code. This reduces the risk to
>>>>> trigger a SIGSEGV accessing meanwhile released pthread objects. And
>>>>> second, it properly detaches joinable pthreads when they are deleted
>>>>> instead. This properly releases the pthread resources.
>>>> I really do not understand that. What is the point of creating a
>>>> joinable thread if you do not want to join it once it has been canceled?
>>>>
>>> Keep in mind that there is no pthread_cancel equivalent in the native
>>> API. Moreover, even POSIX has pthread_detach so that you are not forced
>>> to join every joinable thread. I could imagine that one may want to use
>>> this fot error cleanups. But first of all this is about improving the
>>> API consistency and fault tolerance.
>> I have no strong opinion on that matter, but it looks to me like the
>> "joinable" stuff in the native API is made to look like the posix
>> equivalent, following the principle of least surprise. So, since posix
>> requires joining a thread after canceling, it should be necessary to
>> join a thread after deleting it.
> 
> The problem is that there is no direct equivalent to rt_task_delete with
> pthread. What comes closest is pthread_cancel + pthread_detach (where
> required). Still, rt_task_delete is synchronous, pthread_cancel not.

rt_task_delete looks to me like really equivalent to pthread_cancel.
I do not think rt_task_delete is supposed to be synchronous (it looks to
me it is not if you delete a thread running on another cpu than the
current one). And pthread_detach is not synchronous either. The only way
to wait for a thread deletion is to use pthread_join/rt_task_join.

-- 
					    Gilles.