Re: Threads in Apps
Re: Threads in Apps
- Subject: Re: Threads in Apps
- From: Raphael Sebbe <email@hidden>
- Date: Tue, 5 Jun 2001 21:27:20 +0200
Hi !
Here are some clues about it...
There are many options when it comes to inter-thread communication. From
a Cocoa standpoint, the most common ones are Port Messages and DO
(Distributed Objects). There are other inter-thread comm means (pipes,
socket, mutex/shared mem...), but in your case, you need runloop based
ones because of the AppKit thread, which runs a runloop. (well, NSPipes
could probably do it too...).
Ports : The former allows you to send a message from one thread to a
port, which is processed in the runloop of the other thread. You can
find an example of this in my SpeechUtilities framework, SUSpeaker
class, in the callback (the thread is not explicitly created, it is a
SpeechManager thread, but believe me, it is the same ;-). It shows how
to access AppKit objects from the main thread when something occurs in
the secondary thread. It is listed on Softrak as source code, and there
is an associated Stepwise article on this (search on my name in the
article list).
DO : The latter is more complex but a lot more flexible and powerful. It
basically allows you to transparently send messages to objects (proxies)
using the classic ObjC syntax, the methods being invoked in the other
thread (it internally uses port and runloops as well, but this is
hidden). It is described in NSConnection doc, and there is an example in
/Developer/Examples/Foundation/MultithreadedDO.
There are also AppleEvents, but I am not familiar with those. I know
that a Cocoa class has been added to process those easily, yet I believe
you must use Carbon to send them (correct me if I'm wrong). SURecognizer
in SpeechUtilities framework shows you how to handle aevents using the
Carbon API (from Cocoa), but not how to send them.
Hope this can help you,
Raphael
On Tuesday, June 5, 2001, at 04:33 PM, Dennis C. De Mars wrote:
on 6/5/01 12:31 AM, Nick Emery at email@hidden wrote:
I would like to also ask, as Ken Tabb has, what the best way to set
up a
multi-threaded application without running headlong into problems with
the AppKit not being thread-safe is. Multiple people have asked this
and have not received answers, perhaps they were posting to the
OmniGroup's also, but if there is any good tutorial or sample code for
this or even a paragraph-long design philosophy, what is it?
i would also like an answer to this question as it applies to java and
the
appkit.
so far, the only way have have found that a java subthread can signal
the main
thread (where the ui and appkit are running) is to use an appDefined
event
which is process by an NSApplication subclass and causes suitable
methods to
be invoked in suitable objects. However, this approach is extremely
messy
because the appDefined events get mixed in with the ui events and there
appears to be some strange timing behaviours (i suspect that the ui
events are
forcibly posted at the front of the event queue).
i have tried other approaches in java including: sending a
notification to the
default notification center and to the default queue of the default
notification. both of these approaches result in the target method
being
called in the subthread. I have also tried the distibuted notification
center.
This seems at least to call the target methods in the main appkit
thread, but
it appears to go deaf after a short while.
--nikki
First of all, the document you guys need to read is "Thread Support in
the
Application Kit" which you can find here:
http://developer.apple.com/techpubs/macosx/ReleaseNotes/ThreadSupport.html
People are not finding this because there is no direct link from the
Cocoa
documentation page that I can find. You have to go up to the Mac OS X
documentation page and then go to "Release Note" from there.
It discusses many topics, including a list of the classes that are
"thread
safe" and not "thread safe." I'd take this with a grain of salt
because I
think the document is a little dated, and they don't sound too sure
themselves.
One anomaly I've already found is that the list "NSLock" as thread safe.
Now, that isn't surprising, you'd expect the thread control classes to
be
thread safe if nothing else. But, if you read the "NSLock"
documentation, it
seems to be saying (not in so many words, but in effect) that the
_creation_
of NSLock objects, at any rate, is not thread safe!
Anyway, I haven't used threads in Cocoa myself yet, but I will be doing
so
pretty soon, and I'll probably post some information on the subject.
Regarding Java threads, I would recommend reading the series published
in
JavaWorld (www.javaworld.com) a year or two ago. Hopefully it is still
online. I forget the name of the series, but it was written by Allen
Holub,
so you can do a search. It is very informative and entertaining, and I'd
recommend it to anyone who wants to use threads, whether you use Java or
not. Holub, by the way, feels the thread support in Java is pretty
inadequate, so he shows how to build the tools you need from the Java
primitives.
I don't have an answer for your problems with notifying the main thread
from
a Java sub-thread. Posting to the default notification queue should have
worked...the thing is, a Java thread may not be recognized as a separate
thread by the Cocoa runtime, so that may be causing some problems, but
_surely_ Apple covered this in their Cocoa Java documentation. Is it
possible to use NSThread from Java...or does this have to be a Java
subthread. (I know this issue is dealt with in the Apple documentation,
but
it's probably been over a year since I looked at the Java stuff.)
If I think of anything, I will post it. In the meantime, maybe someone
with
some experience at this knows the answer.
- Dennis D.
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev