cancellation variant for uClibc?

[Peter S. Mazinger]

On Fri, 25 Aug 2006, Mike Frysinger wrote:

> On Friday 25 August 2006 10:20, Paul Brook wrote:
> > > 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).
> >
> > No. The libc version is cancellable, and libpthread does not provide
> > anything.
> 
> for the sake of sanity i'd agree this is the way to go ... that way we dont 
> have to verify every pthread implementation has all the cancel points 
> implemented properly (linuxthreads.old atm is missing a bunch)
> 
> so our libc functions would turn into like (ugly hand typed pseudo code):
> 
> #ifdef UCLIBC_HAS_THREADS
> extern weak_function pthread_setcanceltype(...);
> #endif
> 
> int open(...) {
> #ifdef UCLIBC_HAS_THREADS
> 	int multi_thread = !IS_SINGLE_THREAD();
> 	int oldtype;
> 	if (unlikely(!just_one_thread && pthread_setcanceltype != NULL))
> 		pthread_setcanceltype(ASYNC, &oldtype);
> #endif
> 	<normal open code>
> #ifdef UCLIBC_HAS_THREADS
> 	if (unlikely(!just_one_thread && pthread_setcanceltype != NULL))
> 		pthread_setcanceltype(oldtype, NULL);
> #endif
> 	return <result from normal open code>;
> }
> -mike

we should macroify that and all is set, we can cover with any ugly code 
all the possibilities at one and only location, It is sure not easier to 
keep in sync with glibc but we have to live with it ...

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