I've been investigating further on my problem where the app hangs if I
configure any button to be a blue default button. I had a breakpoint set in
some of my stuff and noticed the nasty cause ---
The blue default button is being drawn from a separate thread, under the
auspices of NSUIHeartbeat, as has been described elsewhere on the net. This
causes a deadlock, however ---- when the hearbeat triggers a redraw of the
button (on thread 21), it needs to redraw the view underneath the button in
order to composite correctly. I have one of my views underneath, and its
drawrect gets called from thread 21. That drawrect sends a message to the
backing object for my view. However, the message handling code knows to look
for this sort of thing (normally it is used for worker threads to send status
updates to the main UI thread) --- so here's the fun part --- the message
sending code drops the call down onto the main thread, ultimately with a
performSelectorOnMainThread.
It looks like the main thread and the heartbeat thread then deadlock trying to
access the same display rectangle (the button's).
My message-handling code is doing the 100% logical and correct thing --- the
drawRect for the view underneath the button HAS to be drawn by the thread that
owns it --- you can see that easily if you consider that the view is drawing
from various program data elements that are designed to accomodate the single
UI thread event flow, and the main UI thread is still running asynchronously as
the button is doing its pretty blue heartbeat.
Offhand I'd say that a separate thread should be drawing to its own separate
buffer, and then composited by a master thread that can handle the interlock
properly. Though having the heartbeat thread call the drawRect routines of
other threads may work most of the time when the button is sitting over a plain
uni-color background, I'm inclined to call this an architectural defect.
So far my ideas on workarounds are
1) see if there's something to be done to make the draw work when it is
executed by the main thread
2) pre-emptively trap the cross-thread draw before it is flipped to the other
thread, and generate a flat fall-back background.
Better ideas or further explanation?
----- Original Message ----
From: j o a r <[EMAIL PROTECTED]>
To: Russ <[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2008 3:51:14 PM
Subject: Re: Blue default button style hangs.
On Nov 12, 2008, at 12:27 PM, Russ wrote:
> All the UI stuff runs on one thread, it's very simple in that sense. There's
> a main [NSApp run] and when you push a button, the modal window pops up from
> inside the left-mouse-down event handler --- creates and populate the modal
> window then does runModalForWindow. The modal window is displayed, but trying
> to click on anything gives you the hung cursor, and pausing the app gives the
> stack trace summarized below.
If you could reproduce this problem in a very small sample project and send it
to me I could take a look. It seems to me that there's something special about
your environment that I'm not aware of, but I'm not sure what it could be.
j o a r
_______________________________________________
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]
