Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Jul 1999 17:44:02 -0700 (PDT)
From:      Jason Evans <jasone@canonware.com>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        Mike Smith <mike@smith.net.au>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c 
Message-ID:  <Pine.BSF.4.05.9907051726240.19167-100000@sturm.canonware.com>
In-Reply-To: <19990705145522.DA40164@overcee.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 5 Jul 1999, Peter Wemm wrote:
> Mike Smith wrote:
> > >   To activate these modifications, add -D_PTHREAD_GSTACK to CFLAGS in
> > >   src/lib/libc_r/Makefile.  Since the modifications depend on the VM_STACK
> > >   kernel option, I'm not sure how to safely use growable stacks by default.
> > 
> > Build enough evidence that VM_STACK doesn't have any downsides, and 
> > then make it non-optional.

Okay, I've tested this pretty well now, and am convinced that it works on
x86.  As for alpha, I have no idea, plus VM_STACK isn't enabled by default
on alpha (according to the man page), so I only turned on growable stacks
for x86.

> It's been on by default for 3.1-release and 3.2-release, and has been unable
> to be disabled on current for ages.  I think it's high time the same happened
> on -stable.  I have not heard any reports of people needing to disable it.

There was some breakage (in at least 3.2 and -current) that Alan Cox fixed
a couple of weeks ago.  Since then, my tests haven't hit any more
problems, but (unless it used to work, and regressed) the VM_STACK code
hasn't been stable for very long.  VM_STACK might deserve a little more
pounding before it's made non-optional.

On a somewhat related note, my threads test programs indicate that there
is likely a significant memory leak in libc_r.  Memory usage grows
steadily, even in the steady state of the programs, which indicates to me
that the leak is is the scheduler somewhere.

Jason



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9907051726240.19167-100000>