Hello, Here is a NSOperation test case that runs fine under OSX but fails on GNUstep.
Scott
concurrent.m
Description: Binary data
On Feb 23, 2011, at 3:43 AM, Fred Kiefer wrote: > 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
