Hi Scott, the best thing to do here is just write a new test case. Show that it works on Cocoa and then we can all work on a fix for GNUstep.
Fred Am 23.02.2011 00:42, schrieb Scott Christley: > Hello, > > So with Richard's recent email about the testsuite and the push for a > release, I tried to look into this bug in more detail. From looking at the > current tests, I can see that there is no test for concurrent operations > which is where I'm having the problem. > > According to Apple's documentation: > > ***** > If you are creating a concurrent operation, you need to override the > following methods at a minimum: > > • start > • isConcurrent > • isExecuting > • isFinished > > In a concurrent operation, your start method is responsible for starting the > operation in an asynchronous manner. Whether you spawn a thread or call an > asynchronous function, you do it from this method. Upon starting the > operation, your start method should also update the execution state of the > operation as reported by the isExecuting method. You do this by sending out > KVO notifications for the isExecuting key path, which lets interested clients > know that the operation is now running. Your isExecuting method must also > return the status in a thread-safe manner. > > Upon completion or cancellation of its task, your concurrent operation object > must generate KVO notifications for both the isExecuting and isFinished key > paths to mark the final change of state for your operation. (In the case of > cancellation, it is still important to update the isFinished key path, even > if the operation did not completely finish its task. Queued operations must > report that they are finished before they can be removed from a queue.) In > addition to generating KVO notifications, your overrides of the isExecuting > and isFinished methods should also continue to return accurate values based > on the state of your operation. > ***** > > Most importantly what this means is that by providing your own start method, > the NSConditionLock which is normally unlocked in GNUstep's NSOperation start > method, is never unlocked, thus the operation queue hangs. > > I'm not completely sure of the correct fix though. Why is a condition lock > even required if the operations are non-concurrent? I presume the condition > lock is actually for concurrent operation, and is being used to release the > next concurrent operation to be run on an available thread (up to the maximum > concurrent threads allowed). But that only seems to make sense for > NSOperationQueue, why does NSOperation also have a condition lock? > > Given that, it seems NSOperation has to be an observer of itself to see if > the isFinished key has been set, then use that to release the condition lock > and let the next operation to run? > > Scott > > > On Nov 24, 2010, at 3:02 AM, Fred Kiefer wrote: > >> I think that in GNUstep you have to create an auto release pool in your >> start method. If this is different from what is needed on Cocoa we may >> have to provide a pool in the _thread method of NSOperationQueue. >> >> Fred >> >> Am 23.11.2010 14:27, schrieb Scott Christley: >>> Yes, I do that, take a look at the "main" method in the code I attached. >>> The errors seem to be coming from the GNUstep NSOperationQueue code, as I >>> can spawn a thread to run the code without getting the error. >>> >>> Scott >>> >>> On Nov 23, 2010, at 1:36 AM, Sašo Kiselkov wrote: >>> >>>> Concurrent operations run in separate threads, which don't automatically >>>> create autorelease pools (which are thread-local). You should enclose code >>>> which runs in a separate thread always in a new autorelease pool. >>>> >>>> -- >>>> Saso >>>> >>>> On 11/23/2010 12:44 AM, Scott Christley wrote: >>>>> >>>>> Hello, >>>>> >>>>> I'm trying to use NSOperationQueue to run a bunch of concurrent >>>>> operations. I used the bit of sample code from the Apple documentation >>>>> for the basic structure, but the code prints some errors and hangs on >>>>> GNUstep. Does anybody know what the problem might be? >>>>> >>>>> I get this from my program on GNUstep, it hangs after doing one operation. >>>>> >>>>> >>>>> 2010-11-22 18:39:29.080 testOperation[3487] autorelease called without >>>>> pool for object (0x199b060) of class GSKVOInfo in thread <NSThread: >>>>> 0x191c4e0> >>>>> 2010-11-22 18:39:29.082 testOperation[3487] autorelease called without >>>>> pool for object (0x199b060) of class GSKVOInfo in thread <NSThread: >>>>> 0x191c4e0> >>>>> starting >>>>> ending: 10000000001.000000 >>>>> >>>>> >>>>> I'm using gnustep-startup-0.25.0 on 64-bit ubuntu. Threads seem to be >>>>> working just fine. >>>>> >>>>> thanks >>>>> Scott _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
