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.kis...@siemens.com>
>> 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.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to