Re: GThread cancellation

["Andres Salomon" <dilinger voxel net>]

> 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..

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).



>
>> >> Is there any particular reason why GThread doesn't have anything
>> similar to pthread's pthread_cancel(), other than the difficulty of
>> implementing such a beast?
>> >
>> > I personally think, that thread cancellation is quite a bad idea.
>> While I'm not completely against it in GLib, I'm sure including it
>> makes a portable thread abstraction much harder with (in my mind)
>> minimal gain.
>
> Bye,
> Sebastian
>
> --
> Sebastian Wilhelmi                 |            här ovanför alla molnen
> mailto:seppi seppi de              |     är himmlen så förunderligt blå
> http://seppi.de