[Debian GNUstep maintainers] request for help: oolite

[Ivan Vučica]

This was my guess too, but it seemed like the use of exitLock is quite
limited. I was not aware it was a recent change :-)

Aside from someone trying to ask Oolite to fix their init, should we also
cut a release of base then?

On Mon, 1 Aug 2016, 12:34 Richard Frith-Macdonald, <
richard.frith-macdonald at brainstorm.co.uk> wrote:

>
> I would guess this is a multi-threaded application and there's a deadlock
> between the two threads initialising various classes in an unusual order.
>
> The general workaround for that kind of thing is to have a single thread
> start things up first (eg have the main thread call [NSDate class] before
> the app goes multithreaded) to ensure that the deadlock can't occur.
>
> Maybe the problem doesn't occur on svn trunk because I recently changed
> the atExit handling code (used by -leakAt:) to use its own lock, rather
> than sharing the gnustep general lock, precisely so that registering things
> for cleanup at process exit will not block things initialising in another
> thread.
>
> In an ideal world multiple threads would not be able to deadlock during
> class initialisation, but the different runtimes have slightly different
> behaviors in the way they lock things during +initialize and I don't think
> it's always possible to write code that's safe with all runtimes ... so I
> think apps need to take some care to initialise things in a single thread
> (and +initialize and +load implementation shouldn't launch new threads
> themselves unless they are *sure* they aren't creating potential for
> deadlock).
>
>