Follow-up Comment #7, bug #35263 (project gnustep):
Hi guys,
Just some thoughts on this: Having per class locks for +initialize is not only
the Apple compatible behaviour, but imho also a contract that is easier to
honour: You just have to keep the set of classes being initialized in thread A
disjoint from those you send messages to from thread B (and vice-versa).
And while I agree that this can be quite tedious for a complex application,
it's even worse with the GCC runtime: If you only got the global lock, you
have to make sure that every single class that might potentially receive
messages in another thread is initialized before you go multi-threaded, which
really isn't feasible at all for a non-trivial application.
For example, in DBusKit I need a whole pile of code that postpones creation of
a worker thread until all +initialize methods in the related DBusKit classes
have run just to work around this limitation of the GCC runtime. Not a single
line of this stuff is actually required with libobjc2.
Cheers,
Niels
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?35263>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep
