[Openmcl-devel] slime, cocoa, autorelease

[Ben Hyde]

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