[bug #35263] libobjc2 can enter a deadlock during dtable initialization

[Richard Frith-Macdonald]

Follow-up Comment #2, bug #35263 (project gnustep):

I would say that the GNU runtime does the right thing here,  but that's
judging by what behavior seems a little more predictable/usable.
If we take the Apple implementation as the reference, then copying that is the
correct behavior.
But both behaviors are correct as far as the documentated behavior of
+initialize is concerned (ie both enforce the rule that no other method of a
class may be executed before the first +initialize of the class completes).

The GNU runtime serialises +initialize by using a global lock to ensure that
only one thread is executing a +initialize method at a time. You can deadlock
it by having a +initialize method block waiting for another thread to do
something which can't be done without the other thread calling +initialize,
but of course the deadlock in this bug report can't occur when +initialize is
serialized using a global lock.

The Apple runtime serialises +initialize using per-class locking, so other
threads can initialise other classes without having to wait.  This will
deadlock if it calls a method  which involves another thread doing anything
with the class being initialized, but won't deadlock when calling methods
which involve other threads initialising other classes.

I like Fred's notion that we could avoid the deadlock reported here, but it's
hard to see how we would do that apart from changing libobjc2 to adopt the GNU
runtime's solution ... which is not much better.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?35263>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/