[Bug-openmcl] processes not gc'd?

[Gary Byers]

On Sun, 29 Feb 2004, Erik Pearson wrote:

> Hi,
>
> It looks like the creation of threads leads to a lot of memory
> allocation that is not recovered by the gc. Here is a small test
> function which creates n threads. I've tried it with n of 100, 1000,
> 10000, etc. and inspected memory allocation with top, and it just grows
> and grows...

I found growth at 10000; I hadn't seen it earlier.

When a thread exits, it deallocates the resources (stacks and semaphores)
it had allocated on creation.  This is pretty simple code and it seems
to work reliably in simple cases.

>
> (defun test (n)
>    (dotimes (i n)
>      (process-run-function ""
>         #'(lambda (j) (+ j j)) i)))
>

The case that I'd want to look at harder is how well-serialized this
deallocation is.  Part of what happens there is that threads remove
things from various lisp kernel data structures, and I'm not sure
that all of those accesses are protected by locks.  (For that matter,
I'm not 100% sure that the additions to those data structures that
occur when a thread's created are properly serialized, so there'd
be two ways to lose here.)  One of the first things that the lisp
kernel does is to allocate a lock ('area_lock'), but that doesn't
seem to be used anywhere.

It seems pretty clear that if two threads try to manipulate the
list of "interesting memory areas" at the same time, Bad Things
Will Happen.  It's less clear that these bad things will include
never getting around to deallocating stacks, etc.


> I discovered this when doing a test of a web-site-monitoring tool which
> uses threads for timouts, and it eventually crashed.

It should work to do so, but there's almost certainly a better way
to do this.

>
> Erik.