[Openmcl-devel] with-autorelease-pool question

[Gary Byers]

Sorry; I don't use SLIME and often forget that things are a little
different in that environment.

If you macroexpand a call to WITH-AUTORELEASE-POOL, you'll see that
it's just something like (function names etc are from memory and
probably not too accurate)

(let* ((#:pool (create-autorelease-pool)))
   (unwind-protect
       , at body
     (send pool 'release)))


The primitive that I'm remembering as CREATE-AUTORELEASE-POOL
just (as one would expect) creates an instance of NSAutoreleasePool
(which I may not be capitalizing correctly) and makes it the
current thread's "active" pool.  Any objects that're sent
"autoRelease" messages (again, beware of capitialization issues)
in the extent of the body are added to the current thread's active
pool, and sending the pool a "release" message first sends "release"
messages to all of the objects that've been added to it, then
makes the thread's previous pool (if it had one) active before
deallocating the pool object itself.

The (non-SLIME) listener colon-commands just do things like
"release the current pool and establish a new one" and "show
information about the current' thread's active pool".  You
ordinarily want autorelease pools to nest dynamically; the
idea of the listener support in "real" listener threads is
that it's better to have a static pool that can be maintained
manually than it would be to get flooded with messages telling
you that no pool is in place.

You can suppress these messages in a SLIME REPL just by calling
CREATE-AUTORELEASE-POOL (or whatever it's called) in the SLIME
REPL, and if you poke around in the sources you can probably
find the primitives that the other colon-commands uses.


On Tue, 22 Aug 2006, Phil wrote:

> Then the problem may be related my access method (i.e. SLIME) as I
> had hundreds (thousands?) of 'just leaking' messages and it took a
> reboot to clean up the swap files.  Any pointers on what SLIME would
> need to do to avoid this issue?  I was under the impression that
> SLIME was just a wrapper around the initial REPL but it sounds like
> there may be more going on than that.
>
> On Aug 22, 2006, at 12:54 AM, Gary Byers wrote:
>
>> Both the initial listener thread (e.g., the one created when the lisp
>> was started from the command-line/emacs/etc.) and any Cocoa listeners
>> that're created should have their own autorelease pools.  Temporary
>> (autoreleased) objects just collect in those pools, but there are
>> colon-commands that're supposed to allow you to manually clean things
>> up every now and then.  (I don't remember exactly what the commands
>> are, but doing :? from a REPL in the Cocoa environment should show
>> you.)
>>
>>
>>
>> On Tue, 22 Aug 2006, Phil wrote:
>>
>>> Can a top-level with-autorelease-pool be implemented in OpenMCL for
>>> interactive development?  A call around the top-level application
>>> code does the trick once all the code is done but I'm wondering more
>>> about doing this for REPL work where I am calling into any number of
>>> entry points and don't want to wrap every function/method 'just in
>>> case.'  (just rebooted as I forgot to do this for some code over the
>>> last few days... ;-)
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>
>>>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>