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

[Alexander Repenning]

On Sep 5, 2012, at 7:49 PM, Gary Byers wrote:

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


We have done some testing. So far it seems as if this is holding up much better. Thank you! Opening up projects will no longer result in the memory surge. 

However, opening up a number of projects and then clicking controls will still result in the memory surge after a while. 

Just to be sure: you did not actually change GUI:EXECUTE-IN-GUI (that one already appeared to have used #/performSelectorOnMainThread previously) but did change CCL::QUEUE-FOR-EVENT-PROCESS and CCL::CALL-IN-EVENT-PROCESS , correct?

There is a lot of event handling code that includes Matt's in-main-thread:

(defmacro IN-MAIN-THREAD (() &body body)
  (let ((thunk (gensym))
        (done (gensym))
        (result (gensym)))
    `(let ((,done nil)
           (,result nil))
       (flet ((,thunk ()
                (setq ,result (multiple-value-list (progn , at body))
                      ,done t)))
         (gui::execute-in-gui #',thunk)
         (process-wait "Main thread" #'(lambda () ,done))
         (values-list ,result)))))



Could there be some bad interaction with the process-wait and the changed functions above?

Why is process-wait used given that execute-in-gui calls #/performSelectorOnMainThread:   with :waitUntilDone:  set to true? I assume it was used to make sure that the call is synchronous, i.e., wait for the function to be called by execute-in-gui to finish. 

thanks,   Alex