[Bug-openmcl] processes not gc'd?

[Erik Pearson]

Gary Byers wrote:

> 
> 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.

Indeed. With DEBUG_THREAD_CLEANUP turned on (and recompiling the 
kernel), it looks as if the thread termination code is not being run 
correctly in the test code. If threads are created one at a time slowly 
(by hand, once every few seconds), the termination code is executed each 
time. However, when threads are created in rapid succession (with some 
overlap) as in the test code, it looks like the cleanup code runs a few 
times, and the stops after which it never runs. Perhaps something is 
deadlocked? I don't know enough about this stuff or the codebase to say 
anything intelligent!

> 
> 
>>(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.
> 
>