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