Hi Rich,
-------- Original-Nachricht --------
> Datum: Wed, 27 Apr 2011 09:11:57 -0400
> Von: Rich Felker <dal...@aerifal.cx>
> An: uclibc@uclibc.org
> Betreff: Re: (Non-)cancellable functions usage
> On Wed, Apr 27, 2011 at 12:46:54PM +0200, Peter Mazinger wrote:
> > OK. let's discuss some implementation details then...
> >
> > 1.
> > static int __pause(void)
> > {
> > blah;
> > /* the return sigsuspend is last */
> > return sigsuspend(...);
> > }
> > a. strong_alias(__pause,pause)
> > b. handle explicitly cancellation
> >
> > we have 2 options:
> > a. call cancellable sigsuspend and do nothing with pause
> > b. call uncancellable sigsuspend and do explicit cancellation
> > support for pause
> >
> > Since return sigsuspend(...) is the last called, probably it does
> > not matter which we opt for, a. provides us with sizewise better
> > results
>
> I would definitely opt for a.
>
> BTW I also wouldn't worry too much about a consistent general policy.
> There are a finite, very small number of cancellation points specified
> in POSIX, assuming you don't want to act on the optional ones (and
> acting on the optional ones generally requires painful cleanup
> handlers all over libc) so it's not a broad-reaching policy matter.
>
> > 2.
> > see poll.c (assume that we do not have poll syscall and we are using the
> > fallback code, there select - as cancellable function is called in the
> mid)
> > What is here the correct approach to get a cancellable poll?
> > How should here cancellation be handled?
> >
> > I think the call to the cancellable select is here not enough, we
> > have to explicitly add cancellation to poll, but if we add the
> > explicit cancellation to poll, then it probably would make more
> > sense to use the non-cancellable select.
> >
> > Which is correct?
>
> >From my point of view, removing the poll emulation would be the most
> correct, or just ignoring that it's a cancellation point. There's no
> system that can correctly support threads but lacks poll. LinuxThreads
> is way too broken to attempt using cancellation with it; you'll just
> end up with unstable, improperly-behaving programs...
poll() was only an example, we have some others like this one...
> Modulo those concerns, in cases like this, the intent of POSIX is that
> the implementation would use pthread_cleanup_push and pop around a
> cancellable syscall to cleanup any temporary state/resources the
> emulation wrapper had used. Of course this aproach results in a good
> deal of bloat for programs that don't use cancellation - it might be
> possible to reduce it with clever use of weak symbols.
this sort of bloat is already added to uClibc_mutex.h since 0.9.28-rc2/3 IIRC
(see the conditional locking, it is a wrongly copied version of the macro
__libc_cleanup_region_start/end from libc-lock.h). Earlier it was only applied
to some special cases in stdio (IIRC fflush...), but now it affects almost each
locking. I have objected at that time for this change, due to the heavy bloat
addition.
Peter
> Another possible implementation-internal approach is to make it so
> that cancellable syscalls don't immediately invoke cancellation
> handlers, but instead return a specially-defined ECANCELED error to
> the syscall wrapper, which the wrapper could then pick up and act on
> cancellation. This is actually the way cancellation should have been
> designed in POSIX from the beginning, returning ECANCELED to the
> application rather than hacking exception-like behavior onto C...
>
> Rich
> _______________________________________________
> uClibc mailing list
> uClibc@uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
