On Mon, 16 Jan 2006 00:58:59 +0000, "lisp" lisp@spikeisland.com wrote:

I am happy to report that this works!

Great!

If you run the function gc-test below in a LWW DLL image, you can see the delegate adapter for the Click event being reclaimed and releasing the closure from the callback hash table.

If you open a process browser window *before* running this, you will see the process created by LWW to handle the callback from .NET's gc thread. Inspecting this process's arguments reveals (rdnzl:%foreign-callable/releasedelegateadapter). This process is used for all subsequent callbacks from the gc thread. If you kill it, a new one will be created for the next gc callback.

If you run this code in a conventional .exe LWW image you do not get the callback from .NET's gc thread.

Thanks for the detailed info. I'll try this tomorrow.

I have run into a further problem - with LWW this time I think. As far as I can tell, LWW will occasionally run a foreign callback on the wrong thread resulting in a stack overflow exception condition being raised. With a form running in a new process and generating event callbacks, the listener process occasionally reports a stack overflow and shows the callback happening in *its* backtrace - presumably confusing the stack check. I've not yet been able to verify this or reproduce it reliably.

Any thoughts or suggestions would be welcome...

No idea. But it would be /very/ helpful if you could reproduce this and submit a bug report to LispWorks support. As you'll know they're currently working on the 5.0 release which will have some changes in the threading code as well. It'd be nice if they could fix that before they release the new version.

Thanks again, Edi.