Re: NSOperation bug

[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
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep