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, < [email protected]> 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). > >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
