Re: NSCondition easter-egg hunt
Re: NSCondition easter-egg hunt
- Subject: Re: NSCondition easter-egg hunt
- From: Ken Thomases <email@hidden>
- Date: Thu, 3 Apr 2008 21:41:39 -0500
On Apr 3, 2008, at 8:14 PM, Jack Repenning wrote:
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.]
On my Leopard machine with Xcode 3.0, NSCondition is documented.
On my Tiger machine with Xcode 2.5, a full-text search of the docs
and the framework headers finds no mention of NSCondition.
It may have existed prior to Leopard, but been private -- never
documented, never exposed in public headers.
[...]
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
I would recommend you look into NSConditionLock (slightly different
name). It is public since ancient times and is substantially simpler
to deal with. You can create the object in Tworker with a condition
value of 0, pass it to the main thread in the
performSelectorOnMainThread... call, lock it when the condition is
1. The main thread receives it and when the user input is available,
sets its condition to 1. Setting the condition can be accomplished
by locking it unconditionally and unlocking it with the new condition.
Cheers,
Ken
_______________________________________________
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