cancellation variant for uClibc?

[Carmelo AMOROSO]

Carmelo AMOROSO wrote:

> 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.

Sorry, the previous mail was not complete; I sent it erroneously.

One thing is not yet clear to me (sorry for that).
What is the policy for uClibc regarding some system functions (open, 
read and so on) ?
If I look at the symbol table of the libuClibc-0.9.28 (SH port, 
linuxthreads old), I can see that
we have a GLOBAL symbol __libc_open and a WEAK open; while in the 
libpthread-0.9.28
there is an UND __libc_open (so it will be bound to the libc's one)... 
right?

Looking at glibc-2.4 (SH, NPTL), I found the following scenario:
__libc_open is LOCAL to libc.so.6
open / __open are WEAK alias for __libc_open.
The same for the libpthread.

With the introduction of NPTL into uClibc, how this will change, if it will?
If I understood what Peter is suggesting, we should have:

__libc_open defined as GLOBAL into libc.so.0 (not cancellable) + open as 
weak alias
 open (cancellable) as GLOBAL into libpthread (and __libc_open an UND 
symbol).

>>>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
>>    
>>
I'll check for it in our implementation.

Thanks,
Carmelo

>>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
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>    
>>>
>>
>>  
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/20060825/0d713838/attachment-0002.htm