cancellation variant for uClibc?

[Peter S. Mazinger]

On Thu, 24 Aug 2006, Paul Brook wrote:

> On Thursday 24 August 2006 02:32, Peter S. Mazinger wrote:
> > Hello!
> >
> > There are 2 ways to go with cancellation support
> > 1. use wrapsyscall.c (provide visible __libc_x() in libc, x() in libc
> > being not cancellable and use __libc_x() that in libpthread to provide x()
> > cancellable (requires proper ordering of libs)
> > 2. go the "NPTL/glibc" way and do the cancellation in libc already
> >
> > old linuxthreads uses 1., nptl branch the latter (new linuxthreads done by
> > me uses 1.)
> >
> > Question to NPTL porters (users of 2.): why are functions duplicated in
> > libpthread that are present in libc already (and are already cancellable)?
> 
> I think glibc defines them in libpthread because that's what linuxthreads did. 
> I'm not sure exactly why, or what (if anything) tries to use the libpthread 
> versions.

I have seen for ex. function in libc as cancellable and non-cancellable in 
libpthread, can't remember though which (in glibc), I cant think of a case 
when this is needed. For dynamic linking as of my understanding due to 
ldso the one in libpthread will win.
Earlier glibc-linuxthreads used the same wrapsyscall.c (maybe at 2.2.x times).
 
> 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.

> There are a few functions where the source is in the libpthread directory, but 
> the objects end up in libc.a/.so
> 
> Paul

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)?
 
Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2