|
From: | Richard Frith-Macdonald |
Subject: | Re: [Gnustep-cvs] r28393 - in /libs/base/trunk: ChangeLog Headers/Foundation/Foundation.h Headers/Foundation/NSOperation.h Source/GNUmakefile Source/NSOperation.m |
Date: | Thu, 16 Jul 2009 08:37:59 +0100 |
On 14 Jul 2009, at 09:15, Fred Kiefer wrote:
Gregory Casamento schrieb:Author: gcasa Date: Mon Jul 13 20:14:42 2009 New Revision: 28393 URL: http://svn.gna.org/viewcvs/gnustep?rev=28393&view=rev Log: * Headers/Foundation/Foundation.h * Headers/Foundation/NSOperation.h * Source/GNUmakefile * Source/NSOperation.m: Initial implementation of NSOperation class. Added: libs/base/trunk/Headers/Foundation/NSOperation.h libs/base/trunk/Source/NSOperation.m Modified: libs/base/trunk/ChangeLog libs/base/trunk/Headers/Foundation/Foundation.h libs/base/trunk/Source/GNUmakefileHi Greg,did you notice that Nikolaus Schaller has added a version of NSOperationto the latest mySTEP code as well? The class itself is less complete than yours, but you might be interested in the subclass NSInvocationOperation and as you know we may freely pick code out of mySTEP and move it to GNUstep, as long as we reference Nikolaus as the author.
Also a few other points ...1. I have been looking into implementing NSOperation for a while, and it's trickier than I initially thought. I had started writing code using locks, but had come to the conclusion that this was a bad idea as things would be too slow for using the class to be worthwhile. I believe that David Chisnall said that Etoile has an implementation of a thread-safe non-locking queue, and this would obviously be worth looking at as a fast thread-safe list of operations appears essential for decent performance of the operation queue.
2. We need to bracket the header file in the macros to say it's only available from OSX5 onwards.
3. Before going further with actual implementation, we need to fix the header files to avoid having instance variables (other than an opaque pointer) visible in the public classes, so that changes to implementation details won't break the ABI in future releases. I'm doing that for all new classes in base. It would be nice to do it for existing classes too, but obviously whenever we change the ivar layout in existing classes we break ABI, which rather defeats the purpose
[Prev in Thread] | Current Thread | [Next in Thread] |