You can also consider creating a singleton class that wraps the worker thread so that you don't always bear the cost of creating the thread just to do some work. This singleon class does need to be thread safe.
Once that's been done provide a way to set the data that needs to be shared and then notify that the data has been posted in a way that the thread wakes up. A very simple way to do this is to have your worker thread class wrap an NSPipe object and the thread routine it self blocks reading on the "server" end of that pipe. When the client side wants to "submit" a request, the internals of a Submit method write a single byte to the "client" side of the pipe which unblock the worker. This pipe approach solve the CPU spin polling issue. You also then wouldn't need to interact with the AppKit classes in your worker thread. Here's a handwavy implementation of what I'm talking about. MyWorkerThread *worker = [ MyWorkerThread sharedInstance ]; [ worker setWorkUnit: workToDo ]; [ worker submitWork; ] --aj ________________________________ From: Jens Alfke <j...@mooseyard.com> To: Philippe Sismondi <psismo...@arqux.com> Cc: Cocoa-dev@lists.apple.com Sent: Fri, March 19, 2010 3:35:40 PM Subject: Re: App modal window and secondary thread On Mar 19, 2010, at 2:31 PM, Philippe Sismondi wrote: > Right - that's exactly my question - I don't know that I have to do this > while loop. Is starting the thread after the window pops up enough? Is there > anything about *not* waiting for NSApplication to set this window as its > modal window that might cause a problem with getting input from the window? You shouldn't be trying to interact with the window at all from a background thread. Most of AppKit isn't thread-safe, and it's also not a clean separation of responsibilities. Thread-safe programming is really, really hard, and the best way to make it simpler is to limit the data shared between threads to the absolute minimum. The best model (IMHO) for background threads is message-passing. You start the thread with some input data, it runs and returns some output data that the main thread receives. If you need to give more data to the thread while it's running, make the thread run a runloop and use one of the threaded -performSelector calls to send it messages. (It can likewise send data back to the main thread the same way.) —Jens_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/andrew_a_james%40yahoo.com This email sent to andrew_a_ja...@yahoo.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
