(Part 3) Thread-safety concerns
(Part 3) Thread-safety concerns
- Subject: (Part 3) Thread-safety concerns
- From: Steve Klingsporn <email@hidden>
- Date: Sat, 2 Nov 2002 23:48:06 -0600
So those are the main problems that I see with this application. I
will gladly supply the source to someone who wants to help me dig into
these problems, if desired, but as I'm charging a meager $5 shareware
fee for the game, I don't really want to put it out in the open because
it's hard to justify asking people for $5 in that case. =)
------
My main concern, actually, is not what's going on with this game, as
much as what could potentially go wrong if I decide to follow-through
on building my next project. My next project is basically a
HyperCard-like authoring environment in a Java-Cocoa application that
uses Netscape/Mozilla's most excellent Rhino JavaScript engine, written
in Java. This is my justification for using Java. I can create a very
nice, rich authoring environment in which users and developers alike
can write code in JavaScript, Java and all that. Since a lot of the
kinds of services and "apps" I'd like to enable creating are either
network-based (and therefore want their own threads), or would probably
be associated with their own JavaScript contexts and therefore would
want their own execution threads, it pains me to think that I might
have to implement my own user interface widgets (though it's not the
end of the world, and actually kinda fun) instead of using Cocoa. I'd
like to let users drag out Cocoa UI objects much like IB (but from
within the environment -- sorta like Squeak allows you to do), inspect
them, and write scripts and such.
If I want to use Cocoa for this, other than using Cocoa as the app
shell for my environment, how would I do this? Wrap everything and
call NSEvents to my main thread? Come on.
This is one main reason that I think Cocoa needs to be thread-safe. UI
objects should not be all that dependent on each other -- they are
independent in nature. The parent/child relationship is a link, but
they should not have any shared data (in theory) which would not allow
them to be called from independent threads, in my opinion. Of course,
I know zero about how Cocoa is actually implemented, etc.
I would love to be able to "lock" a widget, do something with it, and
then "unlock" it. It would be fine with me if another thread that's
waiting to acquire such a lock would block until the lock is released.
This worked on BeOS and the world was a happy place, after you figured
out the tricks and pitfalls of multithreaded programming. I don't know
of any sane way that I can provide the kind of open authoring
environment using Java, JavaScript and Cocoa with Cocoa not being
thread-safe.
------
With regards to someone who was puzzled as to why I would think that
the main thread should be responsive when it is busy, this is where I'm
the confused one:
- If one of the NSButtons beneath my AtaxxView NSView subclass is
depressed, showing the "pushed-in" state (image), NSEvents sent to my
application well up until the button is relased and then are processed
in a big rush of mad activity. Meanwhile, the MoverThread that is
causing the game demo to go on (in the case of computer demo mode in
this case) continues to call display() and displayRect() on my view,
and it's being drawn. If I put the code
System.out.println(Thread.currentThread()) in my drawRect(), I see that
indeed the main thread is servicing these methods...
Huh? =)
Thanks very much for reading this far (I hope). I am not just
bitching. I have been bitten. I'm willing to acknowledge it's my
fault, but based on my experience with programming BeOS, I really think
that Cocoa should be thread-safe. I hope this is on the agenda of the
wonderful folks at Apple who are making Cocoa better and better with
each release. =)
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.