Re: NSOperation bug

[Fred Kiefer]

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