On 4/24/2011 1:36 AM, Peter Mazinger wrote: > Hello, > Hi Peter,
> within uClibc we reuse some of the functions (mostly their __GI_X > counterparts by libc_hidden_proto(). By having the cancellation > in libc, we most of the time reuse the cancellable version I think that this is correct, because we don't know if the libc function is called in a multi-thread scenario that it is going to be canceled. If we use generally a not-cancellable implementation within libc itself, we could prevent cancellation to happen. Make sense ? > Currently we dedicately define (as glibc does) where the non-cancellable > function should be used (by using FUNC_not_cancel*/not-cancel.h). > There are 2 approaches: > 1. use it the glibc-way (and probably adding bloat at runtime for unneeded > cancellation-handling). if there are no threads actually, we just pay for an if (0). > 2. invert the usage and use per default the non-cancellable functions within > uClibc, using the cancellable ones only if it is unavoidable > (or necessary or we benefit sizewise). > At least libc would benefit of this (to reuse these in other libs out of > libc we need to either export them, or provide a structure with pointers > to use them within libpthread/librt). > If the cancellable version is used, it might also be documented, why this > has to happen. > > A good example (although not quite correct) is the use of close() > within libc. In most of the cases close_not_cancel_no_status > would be more appropiate, since there is no error checking done... > > Opinions? > I have much more doubts than opinions :) > Personally I would opt for 2. > Based on my first comment, I'd opt for 1 instead. > Thanks, Peter Cheers, Carmelo _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
