[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NTPL transition

IMHO, there is no need for versioning. Moreover it wouldn't be sufficient.

You must versioning the affected interfaces, otherwise you will never
be able to remove the compatibility code.

Imagine function in a shared library foo which takes as argument
pthread_mutex_t and does usual:

       do some work

And a program bar, which uses foo. Inside bar is a static initialized lock.
The foo might be (re)compiled against NPTL, while bar would be still
compiled against LT. Therefore check_and_reset() should be called as long as
any installed (debian) package have not been recompiled against NPTL. The
overhead of check_and_reset() looks very small, it should be no problem at
all. The harder part is to determine each place, where
check_and_reset() should be called. It have to be in all places,
where static initialized lock might be passed for the 1st time,
i.e. it should be in  pthread_mutex_lock(), but not in

Yes, certainly, this is a valid case.

Any function that manipulates a changed structure needs to be versioned.

Eventually, one day, debian hppa will configure glibc with
--enable-oldest-abi at a high enough value that the compat code will
be dropped (because we have proved no package needs it and we have an
upgrade path).

Do you have any other concerns?

The versioning does not help here, i.e. in the above case
bar will not reference any old (linuxthread variant) function,
therefore it would look like there is no need for compat code, even though it will be still needed.

For dropping compat code, you have to be sure any package is not compiled against old glibc - it can be determined in debian from Depends: line
in binary package control file. The strategy for upgrade might be easy;
For lenny+1 include compat code, but make sure all of lenny+1 released
packages are build against NPTL variant. The compact code can be dropped
just after lenny+1 release.

It looks like one compare will say it is not LT initialized lock,
this path might be really fast.
IMHO, even including such compat code forever will be easier compared to transition all libraries ...

The check_and_reset() should be reasonably "atomic" - two threads might call pthread_mutex_lock() on static LT initialized lock in the same time.

What are the difference between LT and NPTL definition of pthread_mutex_t.
Only 3 unused ints in pthread_mutex_t ?


Reply to: