[Openmcl-devel] Modal dialog problems with CCL 1.9 32/64 on Mountain Lion

[Alexander Repenning]

I can confirm that the #/performSelectorOnMainThread:withObject:waitUntilDone works quite differently from GUI:EXECUTE-IN-GUI. It does not result in a file chooser stall nor (so far) did it produce a memory surge in the <choose-file><run thread> simple test case. We are trying to use a performSelectorOnMainThread:withObject:waitUntilDone based approach in the full app but that has not worked yet. Could be that there are other GUI:EXECUTE-IN-GUI somewhere. 

At any rate. The big question is now that is potentially wrong with GUI:EXECUTE-IN-GUI?


On Aug 30, 2012, at 8:45 PM, Gary Byers wrote:

> If so ... GUI:EXECUTE-IN-GUI is the right idea here, but I'm ignorant enough
> of how dispatch queues work and of how they interact with the Cocoa event loop
> to be a little skeptical of that function's implementation. (To say it again,
> that skepticism is based on nothing more than my ignorance.)
> 
> Another way of doing the important part of what GUI:EXECUTE-IN-GUI does is
> to do it at the Cocoa level; since we're not interested in a return value for
> this test, we can define an ObjC method that does what CHOOSE-FILE-DIALOG2
> does.  (We can define this method on any class; for the sake of argument,
> we'll define a new class here.)
> 
> (defclass example (ns:ns-object)
>  ()
> (:metaclass ns:+ns-object))
> 
> (objc:defmethod (#/chooseFileDialog2 :void) ((self example) arg)
>  (declare (ignorable arg))
>  (let* ((panel (#/openPanel ns:ns-open-panel)))
>    (#/retain panel)
>    (#/runModal panel)
>    (#/release panel)))
> 
> (defvar *instance-of-example* (make-instance 'example))
> 
> (dotimes (i 100)
>  (#/performSelectorOnMainThread:withObject:waitUntilDone:
>    *instance-of-example*
>    (objc:@selector #/chooseFileDialog2)
>    +null-ptr+
>    t))
> 
> It'd be interesting to know whether that behaves any differently for you
> than the one which uses GUI:EXECUTE-IN-GUI.
> 
> My model of how your application works is that the user clicks on a
> button and that causes CHOOSE-FILE-DIALOG to be called (and eventually
> causes problems) and that all happens on the main/event thread.  If
> that's true, then no mechanism for forcing the file panel to open on
> the main thread should be necessary and any difference between
> mechanisms isn't relevant. If the mechanisms behave differently and
> GUI:EXECUTE-IN-GUI is responsible for some of the problem, then we
> should figure out what the issue is and fix it so that things like
> this can be done more reliably, but any (hypothetical) problems with
> GUI:EXECUTE-IN-GUI wouldn't be involved in your application unless it
> works very differently than I assume it does.
> 

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20120905/1a60f03c/attachment.htm>