Threaded events in Cocoa
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?
Is there something inherently wrong with this?
Code:
- (void) beginTask:(id) argument
{
task = initialTaskTool;
[[NSRunLoop currentRunLoop]
performSelector:@selector(continueTask:)
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]
performSelector:@selector(continueTask:)
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?
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...
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.
---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
You could also just use NSNotifications. They are very handy.
"When you dream, there are no rules..."
NSNotifications are single threaded. Besides, they aren't going to help when your code is blocking.
---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
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.
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.
Possibly Related Threads...
Thread: | Author | Replies: | Views: | Last Post | |
Multiple Key Presses - Cocoa Events | JordanReed | 2 | 7,198 |
Jun 23, 2012 07:41 AM Last Post: JordanReed |
|
On DisplayLink & Threaded GL | TomorrowPlusX | 6 | 7,224 |
Aug 12, 2009 02:34 PM Last Post: TomorrowPlusX |
|
Window focus events in Cocoa | Jar445 | 2 | 7,970 |
Jan 18, 2009 06:02 PM Last Post: Jar445 |
|
Should my board game be multi-threaded? | Tasnu Arakun | 2 | 5,336 |
Aug 25, 2006 07:14 AM Last Post: Tasnu Arakun |
|
Quick threaded OpenGL drawing question in Cocoa | TomorrowPlusX | 2 | 5,090 |
Nov 11, 2004 05:23 AM Last Post: TomorrowPlusX |