• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: sending msgs to nsoperation threads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sending msgs to nsoperation threads


  • Subject: Re: sending msgs to nsoperation threads
  • From: "email@hidden" <email@hidden>
  • Date: Thu, 11 Nov 2010 21:00:11 +0000


On 11 Nov 2010, at 20:06, Andreas Grosam wrote:

>
> On Nov 11, 2010, at 4:48 PM, email@hidden wrote:
>
>>> In case you would like to do similar things when using NSOperation and NSOperationQueue you might consider to send the message to the run loop instead, e.g.: -performSelector:target:argument:order:modes:
>>>
>>> Of course you would need a mechanism to get the corresponding run loop for that operation. I would suggest to define a property in your custom operation and set it when the operation enters its main method.
>
> Unfortunately, after more carefully reading the docs, the method
> -performSelector:target:argument:order:modes: seems not appropriate for this tasks since it "schedules the sending of a message on the *current* run loop" - which is certainly not what you want :(   It seems, the receiver of this message is irrelevant, hence the confusion.
>
Definitely confusing. Would make more sense as a class method.
it also says:

You should never try to call the methods of an NSRunLoop object running in a different thread, as doing so might cause unexpected results.

> But there is still the possibility to ask for the current thread in -main and retain it in the custom operation. You may provide it readonly via a property. Likewise, you could then use
> -performSelector:onThread:withObject:waitUntilDone* or you could use custom methods for your operation which invoke performSelector:onThread itself.
> Be carefully though, the operation may not execute anymore or did not yet start when you try to schedule a selector on its thread. Note also, that many operations may be executed on the same thread.

Hmm. I'm not sure that I am convinced of the the case for using NSOperations in situations like this.
NSOperation seems designed to insulate the coder from the underlying thread and here we are digging it out.
Anyhow, next time runloop based concurrency is on the cards I will wrap it in an NSOperation and see how it goes.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >sending msgs to nsoperation threads (From: Shane <email@hidden>)
 >Re: sending msgs to nsoperation threads (From: "email@hidden" <email@hidden>)
 >Re: sending msgs to nsoperation threads (From: Andreas Grosam <email@hidden>)
 >Re: sending msgs to nsoperation threads (From: "email@hidden" <email@hidden>)
 >Re: sending msgs to nsoperation threads (From: Andreas Grosam <email@hidden>)

  • Prev by Date: Re: sending msgs to nsoperation threads
  • Next by Date: Re: RTFDFromRange returns different data
  • Previous by thread: Re: sending msgs to nsoperation threads
  • Next by thread: NSData magic change
  • Index(es):
    • Date
    • Thread