This is the mail archive of the libc-hacker@sources.redhat.com 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] |
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 ld.so 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 redhat.com `---------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |