Re: long uptime memory consumption

[Thomas Bushnell, BSG]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> > I don't know any reason it shouldn't work.
> > There is just the line:
> > 
> >   thread_timeout = global_timeout = 0; /* XXX */
> > 
> > in manage-multithread.c, which Thomas added in 1995 without any
> > rationale given in the log entry or comments (and I certainly
> > don't recall it).  This might just have been to simplify debugging
> > of something else at the time.  You could try removing that line
> > and see what happens.

That was done because there seemed to be hard-to-debug bugs in the
timeouts (it seemed that when a timeout occurred, things went
haywire).  It would be useful to debug it further, unless it seems
like a cthreads bug, and then time is probably better spent
elsewhere.  

> Hurd work (these are brief descriptions; thomas can give more information):
> 
>   * Make the thread timeout in libports/manage-multithread.c work.

Yeah, that's the bug.

>   * Make thread death in C threads really free resources.

C threads death doesn't actually free the thread's stack (and maybe
not the associated Mach ports either).  That's because there's no way
to free the stack after the thread dies (because the thread of control
is gone); the stack needs to be freed by something else, and there's
nothing convenient to do it.  There are many ways to make it work.

However, it isn't really a leak, because the unfreed resources do get
used for the next thread.  So the issue is that the shrinkage of
resource consumption never happens, but it doesn't grow without
bounds; it just stays at the maximum even if the current number of
threads is lower.

This deficiency in cthreads (so long as it persists) makes it less
important to deal with the timeout bug.