I've been using this methodology to drive my application programatically. I've had some sucess doing this in NSThread intances; but lately I find my debugger blows up with SIGBUS when I have something like this in an NSDocument subclass for triggering the first thing that should happen when the user opens a new document.

Is there something inherently wrong with this?


In the threaded case, I pass events to rendering thread that draws until finishes or gets a message to use new data and start over. Seems to work fine.

In the document case, the first selector event loads an NSWindowController with the preceding code, but task is a sheet and continue calls a beginSheet:modalForWindow:...; and each sheets endSelector chooses the next sheet.

It works fine without the debugger, but when the debugger fails on SIGBUS; I wonder the stack was corrupted. Some objects get the ISA pointer switched even thought their dealloc was never called. My code has created one object, loaded 2 nibs and by the time the second object is created the heap may be corrupt. I've tried all the environment settings from malloc_history and NSDebug; but I can't seem to nail down the source of the problem. Any thoughts?

Just for future reference, VolganPoet, it's better to create a whole new thread if you have a question than to raise an old thread from the dead.

gross overgeneralization: AppKit is not threadsafe. Don't call methods on AppKit objects from threads other than the main one. Foundation objects are not locked, so it's not safe to access them from multiple threads simultaneously, though it is generally OK to use them from multiple threads as long as you're careful.

There is a performSelectorOnMainThread: method somewhere you might find helpful...

If you really need interthread communication, you need to look in to Thread Communication and especially Distributed Objects.

You could also just use NSNotifications. They are very handy.

NSNotifications are single threaded. Besides, they aren't going to help when your code is blocking.

If you don't mind using a little C, check out pthread_cond_wait and pthread_cond_signal. Just type man pthread for a reference. This pair is great for "worker" threads.

There are other neat things in pthread.h too - like read/write locks. These are a special type of lock which will grant multiples readers permission to acquire the lock, but only one writer. This is great for fine grained locking, and can help cut down on spinning beach-ball cursors

I tend to use NSThread to spawn my threads (instead of pthread_create), then use pthread's stuff for synchronizing my threads.