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

[Gary Byers]

Just to clarify (I saw Alex's message indicating that our emails crossed):

There are/have been several ways in the CCL IDE code base of forcing
something to execute in the main thread.  All of them ultimately call
either CCL::QUEUE-FOR-EVENT-PROCESS (which simply arranges that the
event process will run a specified function "soon") or
CCL::CALL-IN-EVENT-PROCESS (which waits until the event process runs
the function and returns the value(s) it returns.)  These functions
now default to using #/performSelectorOnMainThread... in preference to
using libdispatch.

User code that uses things like GUI:EXECUTE-IN-GUI shouldn't have to
change.

On Wed, 5 Sep 2012, Alexander Repenning wrote:

> 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
> 
> 
> 
> 
>