cancellation variant for uClibc?

[Carmelo AMOROSO]

Hi,

Paul Brook wrote:

>>>The arm nptl port does not define these in libpthread at all. Any
>>>syscalls duplicated in libpthread are IMHO bugs.
>>>      
>>>
>>Sorry, havent looked at that part of the nptl patch, only the ones
>>affecting the rest of uClibc, but I recall seeing pt-*.c files in the
>>nptl-branch.
>>    
>>
>
>I think the pt-* files are the ones I mention below.
>
>  
>
>>>There are a few functions where the source is in the libpthread
>>>directory, but the objects end up in libc.a/.so
>>>      
>>>
>>that is fine ...
>>
>>New linuxthreads and nptl can go with 2., but how to handle
>>linuxthreads_old (it requires __libc_x() provided visible in libc)?
>>    
>>
>
>I wouldn't expect this to be hard to solve.
>
>On the NPTL branch Steve seems to have decided to add new implementation 
>of/wrappers round all the cancellable syscalls in libpthread/nptl. Hence the 
>big filter-out in libc/sysdeps/linux/common/Makefile.in.
>
>  
>
Yes, this is one of the main question I was going to ask to Steve, 
before starting to merge his code with mine
(I mean the uClibc-nptl port for SuperH at STMicro)

>For the Arm port we added the cancellation code (with appropriate macros) 
>directly into the existing implementations.
>  
>
This is the same approach we used, so if you don't use the NPTL pthread 
implementation, the __libc_XXX functions
will be not cancellable. And we have only one implementation into libc.
We provided both a cancellable/not cancellable implementation for some  
functions (open - close - read - write - waitpid)
requiring both implementation (they are used into 'hostid.c'). They must 
we invoked as <function>_nocancel explicitly (see <not-cancel.h> for 
reference).

Furthermore, the Steve approach, using the PSEUDO macro from 
<sysdep-cancel-h> is adding to the library, for each function,
the relative XXX_nocancel symbol, and I'm not sure it needs.

We already synchronized our code with the arm port to simply the merge, 
but the logic behind
was the same from the beginning.

Carmelo

>Paul
>_______________________________________________
>uClibc mailing list
>uClibc at uclibc.org
>http://busybox.net/cgi-bin/mailman/listinfo/uclibc
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/uclibc/attachments/20060824/baa4cd10/attachment-0002.htm