[Dalgo]

I've never multithreaded anything before and I wanted to multithread a program that I made so that you can still interact with the interface while it is doing stuff. My program works perfectly when I did not try to add extra threads. Then I tried to run a method in a class that I was using into it's own thread by using that whole detachNewThreadSelector thing. It told me that I needed to make some sort of autorelease pool so I put

pool = [[NSAutoreleasePool alloc] init];

at the top of the method and

[pool release];

right before [NSThread exit]; at the bottom of the method. I couldn't really figure out why I needed an autorelease pool because everything that I made in that method I did a retain and then later a release. I guess that I don't really know what an autorelease pool is... but that's not the problem.
The problem is that when I execute the program, it'll run through the method once, and I have no trouble interacting with the rest of the interface at the same time, but then the second time I try to do it quits with a status 255, and above that there are exceptions which don't make sense. You see, nothing plays with any of the variables or anything in that class while my thread is going but one error message that comes up is

*** -[NSMenuItem checkSpellingOfString:startingAt:]: selector not recognized

The only thing is that when I use the checkSpellingOfString method, I am referencing the NSSpellChecker class and not NSMenuItem. Somewhere my pointer got changed or something. Also, when I keep an eye on top while I'm running my program I see it go from 2 to three threads like it's supposed to (I don't know what the second thread could be. It's obviously just part of AppKit or something because I never made another, but it was there even before I tried to multithread my program.) then when it's done, the third thread never goes away. I think that might be part of my problem. I don't really get why the third thread doesn't go away since I put [NSThread exit] at the end of the method that I made a thread.

If anyone could help me with threads that'd be nice. I didn't really get what they were doing in the TrivialThreads sample code from Apple's site and the documentation isn't helping a lot.

[Dalgo]

Okay, I finally found sources on all of that autorelease nonsense, and I understand it now. The only thing that I'm wondering is if the problems with threads that I might be having could be the result of a bug that I saw when I was looking through the Omni mailing list archives. I guess that the Omni developers can only update the display from the main thread or else there are problems. This is supposed to be some type of known problem with application kit. Well, from my secondary thread, I update a NSTextView area in my interface. My other thread is never writing to it while I do this so I know that there can't be any type of problem like that. So I was wondering if anyone knows if this is one of the examples of the type of conflict that I saw described on the Omni mailing list. I also tried using the type of threads in pthread.h, instead of NSThread, you know make my class into a function, but that has the same problems. I can run the thread once, but once the thread is gone and I try to make another new one using the exact same method that I did to create the original it crashes. There are various types of errors but all of them have some sort of selector not recognized thing that doesn't make sense because I never used a selector with the class that it describes.

[Dalgo]

I SOLVED IT!!!

If you want to make threads that update the UI and you don't want your program to crash use:

+ (void)detachDrawingThread SEL)selector toTarget id)target withObject id)argument

From NSApplication instead of anything from NSThread. The reason that I couldn't find this anywhere is because this is one of those things which is listed as "Description forthcoming" in the documentation.

[This message has been edited by Dalgo (edited 01-01-2001).]

[Gametes]

And to think this (Objective-C) is still easier than c++...

[strobe]

Further proof we need better Cocoa documentation. Apple need not provide it, but who else will step up?

(don't ask me, I'm still using PowerPlant)

[petard]

I've seen a few sets of nice documentation:[list=1][*]Stepwise.com... Especially Vermont Recipies[*]Panic.com[*]Some Objective C samples[*]Plenty of Apple Sample Code[*]StoneDesign[/list=a]
These are just the ones I had in my recent history file. I have found that Cocoa programmers are even more prolific than Linux programmers in terms of documentation and answering questions and almost as prolific as Linux programmers in terms of source code samples. Best of luck to you

pétard

[Dalgo]

Okay, Here's a bit of info that can fill in one of Apple's documentation gaps. The problem with Omniweb not being able to draw from other threads doesn't seem to be Apple's fault but just a limitation of how threading works. I wrote to Omni suggesting that they use detachDrawingThread from NSApplication in order to get rid of their problem with writing to the interface from other threads. I assumed that the problem they had was the coflict that exists if you use NSThread to make a thread. Well it's not. If anyone is interested, here's the reply:

Yes, we've experimented with this. In order to draw from a background
thread, the AppKit grabs a lock when it locks the focus on a view.
Unfortunately, since our code is also thread-safe we have to grab locks
when we actually draw. This leads to deadlocks where one thread has the
drawing lock (because it grabbed that before it started interacting with
our logic) and another thread has the model lock (because it was using the
model and decided to draw) and both are wanting the other's lock to
continue.

So, we instead serialize all our drawing through the main thread.

But thanks for the pointer!

Ken

[Dalgo]

Does anyone know how to kill one thread from another thread when I make them with NSThread, not from pthread.h? I'd guess that I just get a thread object from the thread that I want to kill by using

[NSThread currentThread];

and then release that but I'm not sure and that is kind of a pain to do. Also, since I dynamically allocate memory in that thread I'd need to do some cleanup work before I just go and kill it so I was wondering if notifications would be an appropriate thing to use. When a notification is executing, does it prevent all other threads from executing? This really isn't going to play well with other threads if they are trying to run while I'm deallocating their variables. Thanks in advance.