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

[Gary Byers]

On Fri, 21 May 2004, Raffael Cavallaro wrote:

>
> On May 20, 2004, at 8:28 PM, Gary Byers wrote:
>
> > The loop above is trying to close a window that's already been closed.
> > If you really wanted that to work, you'd probably have to do something
> > other than blindly sending a CLOSE messsage;
>
> How would one reliably determine that a window still exists before
> sending it a close message?
>
> (when w (ccl::send w 'close))
>
> still yields the same crash.
>
> tia
>
> raf
>

There are a few issues here:

a) is a window that's been closed still a valid NSObject ?  still a valid
   CLOS object ?

   The answer is complicated, but happens to be "yes" in this case: the
   particular object (the exact EQ MACPTR) returned by MAKE-INSTANCE
   is being retained by code in the bridge; it'll only be released when
   the GC can prove that lisp isn't referencing that pointer anymore.

b) if a window can be closed by multiple threads, how do you ensure that
   CLOSE happens atomically ?

   Um, you write some code (perhaps some fairly complicate code) to ensure
'  that things happen atomically.

   The modified animation code that I mailed out a week or so ago tried,
   but didn't get this right; if anyone's interested, I have some updated
   versions of it.

c) Assuming that (a) and (b) are solved, how can you tell that a window's
   been closed ?

   CLOSE will remove the underlying "window device" (window server window);
   if you ask a window for its window number and it doesn't have a window
   server connection,

   (send w 'window-number)

   will return an integer thats <= 0.

d) Hmm.  How is that case different from a window created with :DEFER T
   that hasn't been displayed yet ?

   I'm not sure that it is.  If you create a window with :DEFER T and
   don't display it, you may not be able to close it without getting
   at least a warning logged to the console.