Re: [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, <address@hidden> 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).