Re: Forks, slices and threads: Can you make GSlice deadlock?

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 7 Dec 2012 22:37:27 +0100
David Nečas <yeti physics muni cz> wrote:
> On Fri, Dec 07, 2012 at 08:44:01PM +0000, Chris Vine wrote:
> > ...
> > So for your scheme to work, the parent before forking must be single
> > threaded.
> 
> As I have learnt the hard way, this is not something I can ensure even
> the program does not use any multi-threading itself because libraries
> may.  Even apparently very innocent programs can exhibit weird
> threading-related bugs.  And while it is a sort of gray area, starting
> to use threads internally is rarely considered an ABI breakage.  So,
> unfortunately, the conditions you listed can be reduced to ‘it will
> never work’ in practice.
> 
> Anyway, I do not attempt to do this kind of fork & not-exec in real
> Gtk+ applications.   So I'm looking forward to a better solution for
> unit tests which is discussed in the bugzilla bug mentioned by
> Matthias.

Ah, OK.  I am not a glib developer.  I just (i) follow this mailing
list because I maintain a library which happens to use glib, and (ii)
know what POSIX says.

It would be hard rations if introducing threads were treated as ABI or
API breakage, and anyway a threading option (now compulsory) has been
in glib from the outset.  Having now read the bug reports another
poster has referred to, the better conclusion is that the test function
in question was wrong at the outset.

Chris