[Openmcl-devel] slime, cocoa, autorelease
bhyde at pobox.com
Fri Feb 5 13:28:44 UTC 2010
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.
>>> -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-
>> etc.) are executed in their own worker threads, though.
> 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
RCS file: /project/slime/cvsroot/slime/swank-ccl.lisp,v
retrieving revision 1.14
diff -r1.14 swank-ccl.lisp
< (ccl:process-run-function (or name "Anonymous (Swank)")
> (flet ((process-function ()
> "If OBJC etc. establish an autorelease pool."
> (let ((pool-special? (find-symbol "*LISTENER-AUTORELEASE-
> ((and pool-special? (member :APPLE-OBJC-2.0
> (progv (list pool-special?) (list (ccl::create-
> (funcall fun)
> (ccl::release-autorelease-pool (symbol-value
> (funcall fun))))))
> (ccl:process-run-function (or name "Anonymous (Swank)")
More information about the Openmcl-devel