[Bug-openmcl] processes not gc'd?

[Gary Byers]

On Mon, 1 Mar 2004, Erik Pearson wrote:

> And it looks like the changes are already making their way into cvs ...
> will this be in bleeding edge? And you'll announce on bug-openmcl?
> (Yeah, I've updated the latest from CVS and see that there is both work
> being done, and some recovery of memory with (gc)).
>

One way to tell whether or not the thread cleanup code works (without
using printf) is to count the Mach threads in the "task".

Since this is the World's Most Advanced Operating System, you have to
allocate a "big enough" buffer before asking Mach to tell you the answer;
this assumes that the answer is <= ~15K:


(defun count-mach-threads ()
  (rlet ((n :mach_msg_type_number_t 0))
    (%stack-block ((buf (ash 60 10)))
      (#_task_threads (#_mach_task_self) buf n)
      (pref n :mach_msg_type_number_t))))

There should always be one additional thread (used in exception handling)
beyond those that (ALL-PROCESSES) knows about, so calling COUNT-MACH-THREADS
in a vanilla OpenMCL should return 3.  After running your thread-creation
stress-test, the number of threads should return to 3; it may take a little
time if there's contention.

I'm pretty confident of that code; I'm not yet convinced that the GC
doesn't need to lock the all_areas list before accessing it.  (If there's
a way to ensure that doubly-linked-list insertions/removals can happen
atomically - by using interlocked loads and stores - that'd be even better.)


>
> Erik.