[Openmcl-devel] slime, cocoa, autorelease

[Ben Hyde]

On Feb 4, 2010, at 10:35 AM, Ben Hyde wrote:

> <?email bottom-posting ?>
>
> On Feb 4, 2010, at 3:19 AM, Tobias C. Rittweiler wrote:
>> Gary Byers <gb at clozure.com> writes:
>>
>>> If I understand correctly, there's no point in trying to implement
>>> the standard REPL's autorelease-pool-related toplevel commands in
>>> SLIME (at least under SLIME's default "communication style".)
>>>
>>> In a Cocoa listener thread (or the original bistener thread in the
>>> hybrid (REQUIRE "COCOA") environment) an autorelease pool us created
>>> at thread startup; autoreleased objects are added to this pool  
>>> when no
>>> more recently-established dynamic pool is in effect.  Some toplevel
>>> commands can be used to examine this global pool's contents and to
>>> release the global pool and its contents and establish a new one.   
>>> (I
>>> -think- that it's the case that the global pool is released when the
>>> thread exits.)  This isn't quite the same as running inside a
>>> WITH-AUTORELEASE-POOL, but it keeps things from completely leaking
>>> (and suppesses those warning messages.)
>>>
>>> When SLIME/SWANK is using the "spawn" communication style, each
>>> form entered into a SLIME REPL is executed in a separate thread.
>>> (I have no idea why, but it does exercise all of the timing screws
>>> that can occur when threads exit and exposes some current bugs with
>>> thread cleanup on Windows ...).  The single global autorelease pool
>>> per thread model can't work in that approach  and the REPL commands
>>> for dealing with that global pool wouldn't be meaningful.
>>
>> That's not quite true. Forms entered into the Slime REPL are all
>> executed in the same REPL thread. All other operations (C-c C-c, C- 
>> M-x,
>> etc.)  are executed in their own worker threads, though.
>>
>> -T.
>
> Tobias is right and I'd go a bit further.  It all works out fine.   
> In my patch I gave all swank's ccl threads an auto release pool.   
> For the "other operations" that mimics the very short lived auto  
> release pools seen in more typical COCOA event handling; which is  
> way useful since lots of COCOA processing needs an auto release pool  
> to own things transiently.   Since the slime REPL buffer gets a long  
> lived thread that auto release pool is conveniently never drained.   
> This is identical to what the IDE's listener is doing, except for  
> the lack of "top level commands."
>
> My current frustration with my patch is that the swank-ccl compiled  
> for #+cocoa is useless if loaded into a leaner #-cocoa image.  It  
> will be ugly, but I think I maybe I'll defer the choice to run time.
>
> - ben

So.  This takes the decision to establishing the autorelease pool at  
runtime rather than compile time.  That's good for you: the swank-ccl  
fasl can load up in vanilla and cocoa flavored sessions.  Fun for me:  
I so rarely get to use progv.

bash-3.2$ cvs diff swank-ccl.lisp
Index: swank-ccl.lisp
===================================================================
RCS file: /project/slime/cvsroot/slime/swank-ccl.lisp,v
retrieving revision 1.14
diff -r1.14 swank-ccl.lisp
732,733c732,743
<   (ccl:process-run-function (or name "Anonymous (Swank)")
<                             fun))
---
 >   (flet ((process-function ()
 >            "If OBJC etc. establish an autorelease pool."
 >            (let ((pool-special? (find-symbol "*LISTENER-AUTORELEASE- 
POOL*" "CCL")))
 >              (cond
 >                ((and pool-special? (member :APPLE-OBJC-2.0  
*features*))
 >                 (progv (list pool-special?) (list (ccl::create- 
autorelease-pool))
 >                   (unwind-protect
 >                        (funcall fun)
 >                     (ccl::release-autorelease-pool (symbol-value  
pool-special?)))))
 >                (t
 >                 (funcall fun))))))
 >     (ccl:process-run-function (or name "Anonymous (Swank)")  
#'process-function)))
bash-3.2$