Re: GThread cancellation

[Sebastian Wilhelmi <seppi seppi de>]

Hi Andres,

> >> It seems to be a necessary evil when dealing with functions that have
> >> the potentional to block indefinitely (libc, xlib, etc).
> >
> > But using deferred cancellation (and using asynchronous cancellation is
> > strongly discouraged [apart from some very few and limited cases]) you
> > have no guarantee either, that those threads are canceled, because they
> > have to wait until they encounter cancellation points. Also I would
> > argue, that a function, which could hang indefinitely is broken.....
> > There are always timeouts, or am I missing something.
> 
> GNU's libc manual lists about 20+ system calls that are cancellation
> points.  I think this would cover most cases (anything using those system
> calls, of course, also become cancellation points).  Overall, though, I
> would want to see asynchronous cancellation support, if cancellation
> support is even added at all..

But cancellation points only mean, that upon entering the function it is
tested, whether cancellation was requested. Those functions are not
interruptible by deferred cancellation.

And concerning asynchronous cancellation I would like to cite the
comp.programming.threads FAQ: (http://www.lambdacs.com/cpt/FAQ.html)

        You CANNOT call any function with asyncronous cancel enabled
        unless that function is explicitly specified as "async-cancel
        safe". There are very few such functions, and sleep() is not one
        of them. In fact, within the scope of the POSIX and UNIX98
        standards, with async cancel enabled you are allowed only to
        
          1. Disable asynchronous cancellation (set cancel type to DEFERRED)
          2. Disable cancellation entirely (set cancel state to DISABLE)
          3. Call pthread_cancel() [This is bizarre and pointless, but it is 
             specified in the standard.]
        
        If you call any other function defined by ANSI C, POSIX, or UNIX98 
        with async cancel enabled, then your program is nonportable and 
        "non conforming". It MAY still be "correct", but only IF you are 
        targeting your code to one specific implementation of the standard 
        that makes the NON-portable and NON-standard guarantee, in writing, 
        that the function you're calling actually is async-cancel safe on 
        that implementation. Otherwise, the program is simply broken.

> I would agree that hanging indefinitely is not proper behavior, but there
> are still plenty of libraries out there that do exactly that, whether
> intentional or not.  Timeouts may be problematic for anything requiring a
> quick response; if they even exist.  Xlib's XNextEvent() is a good example
> of a timeout-less blocking function in a library.  That has the potential
> to hang indefinitely if the Display is no longer receiving events (for
> whatever reason; unmapped, hidden, destroyed, etc).

I don't know much about programming X, so I can't comment on that. Maybe
someone else with more knowledge can comment on that.

Bye,
Sebastian
-- 
Sebastian Wilhelmi                 |            här ovanför alla molnen
mailto:seppi seppi de              |     är himmlen så förunderligt blå
http://seppi.de