Re: Multi-threaded opengl or view access crashes system?
Re: Multi-threaded opengl or view access crashes system?
- Subject: Re: Multi-threaded opengl or view access crashes system?
- From: j o a r <email@hidden>
- Date: Fri, 21 Oct 2005 12:53:10 +0200
On 21 okt 2005, at 12.47, Theo Vosse wrote:
That was another window, but yes, this window already prohibited
drawRect calls. It runs an animation (of a neural network) in a
background thread and drawing is done only there. Of course, that
might be the problem if resizing doesn't do normal setNeedsDisplay/
drawRect calls, and I should leave all drawing to the main thread,
just posting notifications.
<snip>
Yes, the application never blocked before. I've even got menu items
to debug this process by locking/unlocking at will and so far not a
single error, not even on my other machine, which has dual
processors. I follow really simple rules: drawContent takes the
lock and unlocks after drawing, and content altering functions do
the same.
You still need to play by the rules laid out by the AppKit thread
safety guidelines. It might not be enough for you to set up your own
locks for this - you might need to use the locks provided for by
AppKit via the methods provided for that purpose.
I'm afraid the reproduction will be tricky and nothing I'm
interested in provoking.
It's up to you, but it would be good for all of us if you could do that.
Perhaps I should set up another system with a remote login to see
what's happening. It might be that only the window manager is hanging.
Sounds like a good idea.
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden