cancellation variant for uClibc?
Peter S. Mazinger
ps.m at gmx.net
Thu Aug 24 02:23:05 UTC 2006
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
More information about the uClibc
mailing list