Re: MVC and thread-safety
Re: MVC and thread-safety
- Subject: Re: MVC and thread-safety
- From: Steve Klingsporn <email@hidden>
- Date: Sun, 3 Nov 2002 16:49:33 -0600
On Sunday, November 3, 2002, at 04:16 PM, Mike Shields wrote:
Updating the score NSTextFields, of which there are 2 for each
player, overlaid atop each other to provide the "etched" look atop my
brushed metal textured window...[snip]...sometimes for some reason,
they get a little visually out of sync, and the illusion is blown.
This isn't supported since overlapping NSViews isn't supported in
Cocoa. Doesn't matter whether or not your threading, it's just not
supported.
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/
ApplicationKit/Java/Classes/NSView.html
Several references to overlapping views are made.
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/
ProgrammingTopics/DrawViews/Concepts/ViewHierarchy.html#BBCECAIF
"An additional method, addSubview:positioned:relativeTo:, allows you to
specify the ordering of NSViews that may overlap (though laying out
NSViews so that they overlap isn't recommended)."
Says "isn't recommended," but it is supported, and IB has the "move to
front/move to back" functionality. This all works just fine, and is
not why my code is crashing. My code is crashing when I call
setStringValue() from another thread.
As for your threading issues, it seems like it would be simple enough
to set up your own message queue between the two threads for the types
of operations you want to do. Just accept the fact that Java doesn't
have the richness of ObjC for accessing Cocoa and move on.
Cocoa-Java is supported by Apple, and language wars are so 1990.
Thread-safety is so 1993. ;o) If I set up a message queue, how do I
access it? Probably by sending an NSEvent with a reference stuffed in
one of the two data members to the item in the queue? It's not
necessary in this application (which is more or less finished, except
for ironing out these issues), as the operations I'm performing are
very simple.
With ObjC, you could use DO to do what you wanted. with Java, you
would probably be best off stuffing the updated strings into a
NSLocked NSArray acting as a queue. Send an event telling the main
thread to empty the queue. If you have more than one item in the
queue, pull them all out, if you have nothing, ignore the event.
This isn't the problem. And the problem isn't unexpected behavior.
The problem is that in some cases, if another thread besides the main
thread calls into the Cocoa framework, the Cocoa framework blows up.
That's a serious problem.
As far as updating the UI and having the main thread ignore all of
your messages sent from a secondary thread while the user's holding
down the mouse button, well that's just a good idea. How would you
like it if a dialog popped up in your face while you were moving a
text view with the scroll-thumb, or while selecting and dragging in
the field? Letting the user finish what they're doing before you
interrupt them is just good program manners.
Not necessarily a good idea. The case in which a sheet pops up is when
a user makes a connection request. As I stated before, since this is
not a thread-safe thing to do from another thread, it happens from an
NSEvent sent to the main thread, so given the fact that the main thread
can't process two things at once, it happens when the user lets go of
the mouse. The view is locked for input when waiting for the opponent
to move, so the user cannot do anything. The view is updated on its
own (redrawn) from the connection thread just fine -- not a problem at
all.
Apple needs to make Cocoa thread-safe, or at least make it so it
doesn't crash your app if you call a method from another thread.
Steve
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.