Concurrent NSOperation

  • I'm writing an NSOperation subclass which completes it's work
    asynchronously. As such I'm going to have to write a concurrent
    operation.

    The problem I have is that I don't want to have to setup my own
    'runtime environment', quoted from the docs:

    "In your start method, you must prepare the operation for execution,
    which includes preparing the runtime environment for your operation.
    (For example, if you wanted to create a thread yourself, you would do
    it here.) Once your runtime environment is established, you can call
    any methods or functions you want to subsequently start your
    operation. Your implementation of the start method should not invoke
    super."

    I simply need to mark the operation as complete when it receives an
    NSNotification. I could setup a thread but that seems a little
    pointless since that NSOperation is supposed to handle it automatically.

    - Keith
  • On Nov 21, 2007 9:40 AM, Keith Duncan <keith_duncan...> wrote:
    > I'm writing an NSOperation subclass which completes it's work
    > asynchronously. As such I'm going to have to write a concurrent
    > operation.
    >
    > The problem I have is that I don't want to have to setup my own
    > 'runtime environment', quoted from the docs:
    >
    > "In your start method, you must prepare the operation for execution,
    > which includes preparing the runtime environment for your operation.
    > (For example, if you wanted to create a thread yourself, you would do
    > it here.) Once your runtime environment is established, you can call
    > any methods or functions you want to subsequently start your
    > operation. Your implementation of the start method should not invoke
    > super."
    >
    > I simply need to mark the operation as complete when it receives an
    > NSNotification. I could setup a thread but that seems a little
    > pointless since that NSOperation is supposed to handle it automatically.

    Why do you think you need to setup a thread? They only list that as
    something you _could_ do at that point.

    -Shawn
  • > Why do you think you need to setup a thread? They only list that as
    > something you _could_ do at that point.

    Because I want side-by-side execution of my operations, I don't want
    them blocking any one thread waiting for the notification to be
    posted. It could take seconds or it could take minutes.

    - Keith
  • On Nov 21, 2007 10:57 AM, Keith Duncan <keith_duncan...> wrote:
    >> Why do you think you need to setup a thread? They only list that as
    >> something you _could_ do at that point.
    >
    > Because I want side-by-side execution of my operations, I don't want
    > them blocking any one thread waiting for the notification to be
    > posted. It could take seconds or it could take minutes.

    I think you may need to better explain what you are trying to achieve.

    Who is sends this notification? Who is observing this notification?
    Does it have to be a notification?

    -Shawn
  • > I think you may need to better explain what you are trying to achieve.
    >
    > Who is sends this notification? Who is observing this notification?
    > Does it have to be a notification?

    The notification is sent by a PSFeed object when it is finished
    refreshing.

    I'm writing a private update framework similar to Sparkle and the
    operation takes a bundle path and processes it. It uses the new PubSub
    framework to retrieve the appcast details.

    - Keith
  • > I'm writing an NSOperation subclass which completes it's work
    > asynchronously. As such I'm going to have to write a concurrent
    > operation.

    That's not the way it works. For NSOperations, "concurrent" means
    "I'll provide the thread", not "synchronous". From the NSOperation docs:

    "In the context of an NSOperation object, the terms concurrent and non-
    concurrent do not necessarily refer to the side-by-side execution of
    threads. Instead, a non-concurrent operation is one that executes
    using the environment that is provided for it while a concurrent
    operation is responsible for setting up its own execution environment."

    followed by

    "For a non-concurrent operation, an operation queue automatically
    creates a thread and calls the operation object’s start method..."

    So, basically, for simple asychronous behavior just subclass
    NSOperation and override -main. NSOperationQueue will be responsible
    for creating the threading "environment", within the parameters set
    (e.g. -setMaxConcurrentOperationCount:).

    Karl
    >

    --

    If Goddess had intended humans to smoke, She would have set them on
    fire.

    Homepage:
          http://homepage.mac.com/khsu/index.html
  • > So, basically, for simple asychronous behavior just subclass
    > NSOperation and override -main. NSOperationQueue will be responsible
    > for creating the threading "environment", within the parameters set
    > (e.g. -setMaxConcurrentOperationCount:).

    OK, but how will I mark the operation as still executing and
    unfinished until the notification is posted?

    Are the docs stating that concurrent operations MUST override
    isExceuting and isFinished etc, but that non-concurrent ones can if
    they so choose?

    I do understand the difference between a concurrent and a non-
    concurrent operation, but I also think that the use of the word
    "concurrent" in a context where threads are being used will lead to
    confusion. I think I'm going to file a bug on that one.

    - Keith
  • "preparing the runtime environment" is fairly vague because there are
    many different situations that might crop up for operation usage.  In
    this particular case, it sounds like "preparing the runtime
    environment" could be interpreted to mean "add the operation as an
    observer of the notification to the notification center".  And -
    isConcurrent can be overridden to return YES.  If nothing (like your -
    start method) is going to refer to -main, you need not implement one
    in the subclass.

    In your notification handler method, you should make sure to maintain
    KVO compliance, either by manually invoking the will/didChange
    methods, or by creating a "finished" state in your subclass, and
    implementing -setIsFinished: to return that state, a -setIsFinished:
    to set that state, and invoking setIsFinished: from the notification
    handler.  You'll want to override
    +automaticallyNotifiesObserversForKey: to return the correct answer
    (NO or YES respectively) for the @"isFinished" key.

    Or something along those lines.

    Chris Kane
    Cocoa Frameworks, Apple

    On Nov 21, 2007, at 9:40 AM, Keith Duncan wrote:

    > I'm writing an NSOperation subclass which completes it's work
    > asynchronously. As such I'm going to have to write a concurrent
    > operation.
    >
    > The problem I have is that I don't want to have to setup my own
    > 'runtime environment', quoted from the docs:
    >
    > "In your start method, you must prepare the operation for
    > execution, which includes preparing the runtime environment for
    > your operation. (For example, if you wanted to create a thread
    > yourself, you would do it here.) Once your runtime environment is
    > established, you can call any methods or functions you want to
    > subsequently start your operation. Your implementation of the start
    > method should not invoke super."
    >
    > I simply need to mark the operation as complete when it receives an
    > NSNotification. I could setup a thread but that seems a little
    > pointless since that NSOperation is supposed to handle it
    > automatically.
    >
    > - Keith
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today