This is the mail archive of the mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

more cancellation work

I've checked in some more cancellation work today.  It took a while to
get this done mainly because I went back and forth on some of the
decisions.  This is the time when policies have to be made and I think I
got it down to some reasonable set now.

The problem is the set of functions which POSIX lists as possible
cancellation points plus all the functions not in POSIX.  If the
implementation of the functions uses a function which is a cancellation
point it can also become cancelable.  And in fact it will unless steps
are taken.  For each function a decision has to be made.  In case the
decision is to not make a function cancelable a not-cancelable version
of the syscall wrapper has to be used.

The decisions I made so far are as follows:

~ functions needed for error messages etc are not cancelable.  This
includes catgets, gettext, strerror.  This will allow generating some
output before a thread dies.

~ if possible, all functions related to closing a descriptor are not
cancelable.  Unfortunately close() itself must be cancelable since POSIX
says so.  But think a second what this means.  If close() is canceled it
is not known whether the descriptor has been closed or not.  I.e., the
program leaks.  Better avoid this if possible.

~ the dlfcn code is not cancelable.  Mostly because most of the code is
in and there it is not cancelable.

~ the headers reflect exactly the cancelability of the function.  I.e.,
even if a function is listed in POSIX as a possible cancellation point
but it is not cancelable in glibc, it still gets the __THROW marker.

I have also introduced some code which inside glibc itself uses the C
cleanup handling.  The use of this feature will increase significantly
in future.  But using it brought up a problem: the unwinder code is now
used internally.  This causes problem since we already compile in parts
of unwind-dw2.c.  If now the other unwind code is pulled in from
libgcc_eh.a we get a collision of symbol due to the few symbols we
already have from our own copy of unwind-dw2.c.  rth said he doesn't
want to split the file to avoid exposing more interfaces.  This means we
have to pull in all of the unwinder code which might mean we get
maintainance problems in future where old glibcs cannot be compiled with
new gccs.  I see no other solution for this.

Another problem is ia64.  The unwinder code for ia64 is different from
the rest.  We probably need to pull in that code from gcc as well.  I
haven't done it yet which means ia64 might not link/run correctly.

Anyway, there is a lot more work to be done.  All possible cancellation
points have to be investigated.  Then all functions implementations need
to be investigated whether they are using (transitively) and cancelable
function.  In case this is the case and the function is in POSIX the
code must e rewritten to avoid the cancellation points.  Otherwise we
have to make a decision.

The whole matter is worse since I know this feature will hardly ever be
used (and rightly so).  It's such a waste.

--------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at `---------------------------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]