|
From: | Ivan Vučica |
Subject: | Re: [Debian GNUstep maintainers] request for help: oolite |
Date: | Mon, 01 Aug 2016 11:38:54 +0000 |
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).
[Prev in Thread] | Current Thread | [Next in Thread] |