cancellation variant for uClibc?

Carmelo AMOROSO carmelo.amoroso at st.com
Fri Aug 25 06:19:38 PDT 2006


Peter S. Mazinger wrote:

>On Thu, 24 Aug 2006, Carmelo AMOROSO wrote:
>
>  
>
>>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.
>>    
>>
>
>Then I would propose to do that for all threads variants, get rid of the 
>__libc_x versions, no need for wrapsyscall.c in linuxthreads_old
>
>Consider though to replace all the similar code starting with
>if (SINGLE_THREAD_P)
>	...
>with a macro like in wrapsyscall.c (I have proposed this when I commented 
>on the arm port already)
>
>
>  
>
Well, it could be a good choice, so no needs to changes the __libc_x 
from linux/common directory.
We need an agreement among different ports... I'd like to hear from 
Steve, because is approach is very
different.

>>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).
>>    
>>
>not-cancel.h is also a header that should be addable unconditionally to 
>each source file, I would propose something like this to be added to it
>#ifndef __UCLIBC_HAS_THREADS__
>#define <function>_nocancel somefunc
>#endif
>for all functions that have cancellable/not cancellable pairs
>I assume <function>_nocancel are implemented as non-visible in userspace
>
>Peter
>  
>
>>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://busybox.net/lists/uclibc/attachments/20060825/699fb45f/attachment.html 


More information about the uClibc mailing list