Hi! I put together a testcase, this used to work before the switch ObjectiveC2 framework. Lin 62 is the one causing the crash.
Thanks TOM Zitat von ici...@mail.cg.tuwien.ac.at:
Hi! looks like it is not fixed :( Richard ported the code over to the ObjectiveC2 framework immediately, but it still does not work. Now I get "Uncaught exception NSInvalidArgumentException, reason: (null)(class) does not recognize instance". As "instance" is the class method which creates the singleton now something else seems to go wrong. Thanks TOM Zitat von David Chisnall <thera...@sucs.org>:I've now fixed this case in libobjc2. Unfortunately, someone decided to 'helpfully' reindent the version of ObjectiveC2.framework in GNUstep, which means that diffs from libobjc2 no longer cleanly apply in ObjectiveC2 (nor to diffs against the original version in Étoilé svn), so whoever did that gets to volunteer to back-port the changes. On 27 Feb 2010, at 17:40, Richard Frith-Macdonald wrote:You are probably in a better position than anyone else to be aware of precisely what parts of ObjectiveC-2 are most efficient or inefficient, and how they compare to the traditional ways of doing things. Have you considered producing a paper describing those differences? If we had them quantified we would have a really good guide for people to know when to use new features and when to avoid them (and when it really doesn't matter).Well, I did write a book that describes them... @synchronized is basically impossible to implement efficiently. It's a stupid feature added to make life easier for Java programmers who are too lazy to think when they learn a new language. There are basically three ways you can do it: 1) Allocate a pthread_mutex_t with every object Pros: Fast, simple Cons: Wastes at least one word of memory for every object, including the 99.9% that are never used as arguments to @synchronized(). 2) Have a shadow data structure mapping objects to locks. Pros: Doesn't waste much memory. Cons: Extra locking on the shadow structure needed, extra code needed to remove locks when they are no longer needed, overhead performing the lookup. 3) Add a hidden class between the object and its real class which stores the lock. Pros: Relatively simple and non-invasive. Cons: Needs an extra class structure for every locked object. libobjc2 / ObjectiveC2.framework use option 3. We use objc_allocateClassPair(), which doesn't work for creating just a new metaclass (although we fail slightly more gracefully than Apple's version, which just returns a pointer to a random address). I've now added a special case to libobjc2 and a non-portable runtime function for allocating just a new metaclass. In all cases, this pattern will be much faster: [nslock lock]; @try { // do stuff } @finally { [nslock unlock]; } It's also worth remembering that @synchronized uses a recursive mutex, which, on most platforms, is slower than the non-recursive form used by NSLock. Unless you actually need the recursive behaviour, don't use it. @synchronized is a horrendous language feature, because it looks just like the Java keyword, but has almost the exact opposite performance characteristics. David -- Sent from my Difference Engine_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
synchronized.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev