Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> GIT version control wrote:
>>>> Module: xenomai-jki
>>>> Branch: for-upstream
>>>> Commit: 0352b068600bd4ef3172c8a42416badbcdad32ca
>>>> URL:    
>>>> Author: Jan Kiszka <>
>>>> 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.

> As for pthread_detach, its main justification is a corner case: being
> able to avoid leaks when canceling a thread which was blocked in a call
> to pthread_join by calling pthread_detach in the cancelation cleanup
> handler.
> The reason for the way the native API is, is that you may delete a
> thread which is in fact running in another process. And I am not sure
> the patch you sent addresses this issue.

I does not. And thinking about it, I guess we should simply deny remote
deletion of joinable tasks as there is no reasonable way to cleanly
release the remote pthread resources. I could post an update for code
and docs on top of this.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to