Hallo David, Am Thu, 30 Jul 2009 15:12:05 +0100 schrieb David Chisnall <[email protected]>:
> I didn't propose optimisations here. When I rewrote the NSLock > classes to use pthreads, I halved the amount of code and added an > implementation of NSCondition. To me, less code which does more is > more maintainable. > > The fact that, because it isn't using the buggy and largely- > unmaintained abstraction layer in libobjc is an added bonus. The code > in libobjc uses recursive mutexes. It does not create or destroy > threads, and it does not use condition variables. This means that the > functions for doing any of these things in libobjc are not tested by > libobjc and in some cases are just stub implementations which always > return NULL. Depending on these, rather than well-tested pthread > implementations does not make sense. This reminds me that I have a patch somewhere which fixes this problem. (Essentially, by copying from ... well I forget, but I'm sure I can find out ... a variant of this particular threading package that *does* implement the missing routines, anyway). Now, I don't know how well-tested this currently is, but I'm pretty certain that modern gcc relies on these routines for both Java and OMP (both of which I recall having problems on Windows which might well be related), not only for libobjc, so there is certainly hope that bugs in there will actually be found. I need to find some round tuits and submit that patch ... Mit freundlichen Grüßen aus Münster / with kind regards - Kai Henningsen -- SPUeNTRUP Software Windbreede 12 D-48157 Münster, Germany Reg: Münster Nr.29047 Fon: +49 700 CALL CATS (=22552287) Fon: +49 251 322 311 0 Fax: +49 251 322 311 99 GSM: +49 171 7700992 Web: http://www.cats.ms Mail: [email protected] _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
