• 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: Return Code Dilemma
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Return Code Dilemma


  • Subject: Re: Return Code Dilemma
  • From: "Louis C. Sacha" <email@hidden>
  • Date: Thu, 29 Apr 2004 16:24:58 -0700

Hello...

Two possible ways of dealing with this might be:

1) using Notifications to return the result -- you could store the return code (as an NSNumber) in the userInfo dictionary of the notification. The method that spins off the thread could return void, or return some sort of object or tag that the calling object can use to find the correct result. When the thread completes it's work, it could use NSNotificationCenter and performSelectorOnMainThread:withObject:waitUntilDone: to call the postNotification: method on the main thread.

2) Have the calling object provide a target and callback selector which your spun off thread can use to return the results.

Either way, if the object that starts the process is not interested in the results, they (1) would not have to register for the notification or (2) could indicate it by providing nil+NULL for the arguments.


Hope that helps,
Louis

Hi all, I've a rather broad design question here...

I am working on a class that does all of it's work by a single public class method being called. The class method creates a new instance and does a bunch of calculations and network stuff in a new thread, then cleans up the instance it created. The created instance is completely private. I'd like to have the class method return integer codes based on the results of the calculations in the new thread.

The problem is that waiting for the results of the instance's thread in the class method (which needs to be in the main thread), means that the instance may as well be doing everything in the main thread.

Are return codes even viable in these circumstances? The instance takes some time to do its calculations and if the network is slow, it may take even longer. Thus there's no way of knowing when the return code will even be available. Is a return code even useful? In this situation, how might each of you gather this information that will become available at an unknown time after the class method is called?

Any thoughts are appreciated, even if they may steer my project in a different direction.

-- Daniel Currie
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Return Code Dilemma
      • From: Allan Odgaard <email@hidden>
References: 
 >Return Code Dilemma (From: Daniel Todd Currie <email@hidden>)

  • Prev by Date: Re: Cocoa everywhere?
  • Next by Date: NSTextView binding redisplay
  • Previous by thread: Return Code Dilemma
  • Next by thread: Re: Return Code Dilemma
  • Index(es):
    • Date
    • Thread