• 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: NSRunloop + shared thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NSRunloop + shared thread


  • Subject: RE: NSRunloop + shared thread
  • From: Colin Deasy <email@hidden>
  • Date: Thu, 19 Nov 2009 23:40:14 +0000
  • Importance: Normal

I see what you mean but at the moment Im finding it hard to see another avenue. To give a bit more detail on the situation. This shared thread is actually handling potentially large numbers of concurrent url connections/downloads. The reason that I want a block in some of those at different times is a for a form of bandwidth control I am trying to do. I know I could do this by having a separate thread for each task but there is quite a lot of overhead with that and from the tests I have ran, it spins too much.

> Subject: Re: NSRunloop + shared thread
> From: email@hidden
> Date: Thu, 19 Nov 2009 15:21:37 -0800
> CC: email@hidden
> To: email@hidden
>
>
> On Nov 19, 2009, at 2:54 PM, Colin Deasy wrote:
>
> > I have a shared thread that is used to process multiple asynchronous tasks. But at some point, a task may need to 'pause' its execution, and cannot exit its method and wait to be re-called, how can I do this?
>
> They're not really asynchronous tasks if they need to block. You might try to refactor your design so nothing blocks — this usually involves converting local state inside a method, into state in an object's instance variables. If you can limit yourself to 10.6, using blocks can help a lot in this.
>
> > In that method, where a 'pause' instance is brought about, can I use something like the following to wait, but not block the run loop?
> > while(condition)[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalFromNow:0.01]];
>
> The short answer is "yes". The full answer is that while this is tempting, and it can be made to work, it enables complicated forms of re-entrancy that can produce very unexpected results that are hard to debug. The problem is that external state can change out from underneath your handler while it's waiting like this, as other handlers run. You can even get the same handler invoked in nested form. Or you can get the opposite problem, where the outer handler sets some state (such as acquiring a lock) that breaks other nested handlers when they try to access the same state.
>
> Several times I've managed to catch a crash, then scrolled down the call stack and gone "oh shit!" as I see the multiple layers of handlers. I would recommend you not go this route.
>
> —Jens

_________________________________________________________________
New Windows 7: Find the right PC for you. Learn more.
http://windows.microsoft.com/shop_______________________________________________

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

  • Follow-Ups:
    • Re: NSRunloop + shared thread
      • From: Jens Alfke <email@hidden>
    • Re: NSRunloop + shared thread
      • From: Kyle Sluder <email@hidden>
References: 
 >NSRunloop + shared thread (From: Colin Deasy <email@hidden>)
 >Re: NSRunloop + shared thread (From: Jens Alfke <email@hidden>)

  • Prev by Date: Re: Trouble finding bounding rect of NSAttributedString
  • Next by Date: Advice about crash requested
  • Previous by thread: Re: NSRunloop + shared thread
  • Next by thread: Re: NSRunloop + shared thread
  • Index(es):
    • Date
    • Thread