[Openmcl-devel] Re: [Bug-openmcl] NSViewHierarchyLock Assertion failure

[Gary Byers]

On Tue, 11 May 2004, Raffael Cavallaro wrote:

>
> On May 11, 2004, at 6:55 AM, Gary Byers wrote:
>
> > I can't reproduce this problem, but I'm willing to believe that it
> > exists (and don't think that changing/reverting the method definition
> > has too much to do with it.)
>
> FWIW, I've been playing around with simple changes to tiny.lisp,
> renamed as tiny-loop.lisp, such that the drawing of polygons loops
> (animates), and I've found similar problems. In particular, closing the
> window while the animation is running will often, though not always,
> cause OpenMCL to crash. (On an unrelated side note, I've also seen some
> tearing in the drawing).

How does it crash ?  Is there any output generated anywhere, does the
beachball cursor appear and not got away, or does something else happen ?

>
> I've found that first entering a break loop before closing the drawing
> window prevents this crash.
>
> Before loading modified code, I've also found that crashes can be
> prevented by first removing TINY-LOOP from cl-user::*modules* while in
> the break loop.
>
> So, some practical suggestions:
>
> 1. Don't try to execute modified drawing code to an existing Cocoa
> drawing window. Enter a break loop, close the existing window, remove
> the module from cl-user::*modules*, then reload it with (require
> 'whatever) if you've been using require, or just (load …) it, if you've
> been using load.

I'm very, very skeptical that the presence or absence of a string on
*MODULES* or the break level of a listener thread has any direct,
deterministic effect on the "tiny" demo's behavior.

>
> 2. Don't try to close a drawing window while it's drawing - I assume I
> need some sort of window-closed method, either in Objective-C or MCL -
> no? Unfortunately, I don't know what level this needs to be at (should
> the loop check that the window is still open before trying to draw each
> time through?) At what level of granularity would I need to check -
> before drawing each line? Each polygon?

Drawing (the drawRect: method) ordinarily happens on the main Cocoa
event thread, as does the response to a mouse click in the window's
close box (er, um, the throbbing red button ...).  That thread can
either be drawing or responding to the mouse click; it can't be doing
both at the same time, and it isn't necessary for the drawRect: method
to be particularly aware of the possibility that window might close
(or that it might be iconized, or resized, or moved, ...)

Unless, of course, drawing happens on some other thread, or the drawRect:
is called by something other than the Cocoa redisplay code running on the
main event thread.  In the unmodified TINY example, something like this
might happen if a listener thread tries to display the window and the
event thread decides that it'd be a good time to call the view's drawRect:
method.  Forcing the window display to happen on the Cocoa event thread
didn't seem to reliably fix the problem for Sebastian Nozzi, but I tend
to think that the problem he originally reported is related to the fact
that a window's being created in a thread other than the Cocoa event thread
(and it's content view is being changed and delegate being set from that
thread ...)

If two threads try to access/modify a window and its view hierarchy
"at the same time" - and don't try to synchronize with each other in
any way - it would be surprising if this worked reliably (and would
ultimately depend on what "at the same time" means.)  "at the same
time" in turn depends on many factors, including how many processors
are available and what kind of recent activity has occurred in each
thread.  If things like redefining methods, changing *MODULES*,
etc. affect this, I strongly suspect that it's because that activity
influences which threads run when.

>
> Of course these suggestions don't get at the real problem, but they do
> make learning the Cocoa bridge significantly easier.
>
> BTW, I'm running MacOS X 10.3.3, and OpenMCL Version (Beta: Darwin)
> 0.14.2, but all of the above has been true since early this year when I
> first started playing around with tiny.lisp.

I still haven't been able to reproduce this problem with tiny.lisp, but
I've been bitten by this sort of thing often enough that I'm becoming
compulsive about forcing all UI-related stuff to happen in the main
event thread.  (In a typical Cocoa application, just about all UI-related
stuff happens in that thread - in response to a menu action or some other
event.  Apple has a Tech Note or QA somewhere which claims that the long-
held folklore that the AppKit isn't thread-safe isn't entirely accurate;
I don't believe that the TN/QA's entirely accurate, either ...)

>
> Raf
>
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro at mac.com
>