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 PROTECTED]
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to