[Openmcl-devel] slime, cocoa, autorelease

[Tobias C. Rittweiler]

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.