Re: NSOperation bug

[Scott Christley]

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
>