iDevGames Forums
Threaded events in Cocoa - Printable Version

+- iDevGames Forums (
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Threaded events in Cocoa (/thread-5535.html)

Threaded events in Cocoa - VolganPoet - May 10, 2005 04:34 PM

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?

- (void) beginTask:(id) argument
  task = initialTaskTool;
  [[NSRunLoop currentRunLoop]
     target: self argument: argument
     order:100 modes: [NSArray arrayWithObjects: NSDefaultRunLoopMode, nil]];

- (void) continueTask:(id) argument
     // call something that uses taskObject
     // something sets task to the next thing to do
    if ( task != nil )
        [[NSRunLoop currentRunLoop]
            target: self argument: argument
            order:100 modes: [NSArray arrayWithObjects: NSDefaultRunLoopMode, nil]];

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?

Threaded events in Cocoa - Josh - May 10, 2005 04:45 PM

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. Smile

Threaded events in Cocoa - OneSadCookie - May 10, 2005 07:24 PM

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...

Threaded events in Cocoa - kelvin - May 10, 2005 07:41 PM

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

Threaded events in Cocoa - Taxxodium - May 11, 2005 05:20 AM

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

Threaded events in Cocoa - kelvin - May 11, 2005 02:50 PM

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

Threaded events in Cocoa - Andrew - May 11, 2005 05:24 PM

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 Wink

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