NSCondition easter-egg hunt
NSCondition easter-egg hunt
- Subject: NSCondition easter-egg hunt
- From: Jack Repenning <email@hidden>
- Date: Thu, 3 Apr 2008 18:14:38 -0700
So, what's the scoop on NSCondition? Can someone lead me out of the
woods? I can't formulate a coherent question, only a list of bits of
documentation which appear to me to contradict each other every way
from Sunday. Am I misreading something, or are some few of these wrong?
(1) When did NSCondition come to be? Cocoa Fundamentals Guide (as
contained in my Leopard Xcode) has a Note: "The NSCondition class was
introduced in Mac OS X v10.5. It is not available in earlier versions
of the operating system." That would mean I can't use it, since I
need to support 10.3.9 (and build on either 10.4 or 10.5). But
clicking that word "NSCondition" in that very note leads to the class
reference page, which says "Available in Mac OS X v10.0 and later."
Eh? [Some of the individual methods are marked 10.5 (the name stuff),
but I don't care about 'em.]
(2) What are its methods? Thread Programming Guide's "Using the
NSCondition Class" section shows examples with the methods -lock, -
wait, -signal, and -unlock. The reference manual lists -wait, -
waitUntilDate:, -signal, -broadcast, -setName:, and -name (nothing
about lock, an odd omission for a semaphore class). None of these
mention any special initializers. If I create one:
NSCondition *theCondition = [[NSCondition alloc] init];
and then try these various names (for example, [theCondition lock]), I
get "method not found" on -broadcast, -wait, -signal, -waitUntilDate:,
and -setname: -- everything except -lock, -name, and -unlock.
Well, OK, I guess I can formulate a question: how do I synchronize
threads? In particular, I have a worker thread (which I spun off long
ago, using detachNewThreadSelector:, which discovers that it wants to
ask the user for additional info (a password, as it happens). I've
registered a call-back for this purpose. When the call-back is
called, I need to materialize a dialog for the user input, and as I
understand it all GUI stuff needs to happen on the Main Thread, where
at the moment I ain't. So I
performSelectorOnMainThread:withObject:waitUntilDone:, but I need to
block -- not only until the selector finishes (which is what I get
from waitUntilDone:), but actually until the user completes the
dialog. My original worker thread needs to wait on something, say an
NSCondition, until the code supporting the dialog completes (and
signals).
Tmain: detachNewThreadSelector: and go on about your business
Tworker: workee workee, oops, need a password
Tworker: performSelectorOnMainThread:withObject:waitUntilDone:
Tworker: suspend at this point somehow, but how? <<<<<<<<<<
Tmain: post prompt sheet, collect input, close sheet, load answers
somewhere shared
Tmain: wake up Tworker (and go on about your business)
Tworker: wake up, grab the values, and go on about your business
-==-
Jack Repenning
email@hidden
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden