gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] r28393 - in /libs/base/trunk: ChangeLog Headers/Founda


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/GNUmakefile


Hi Greg,

did you notice that Nikolaus Schaller has added a version of NSOperation
to 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]