[Openmcl-devel] Re: [Bug-openmcl] NSViewHierarchyLock Assertion failure
gb at clozure.com
Fri May 21 03:18:01 EDT 2004
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.
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
(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.
More information about the Openmcl-devel