[PATCH] Dynamic thread stack size

[Joe Marcus Clarke]

On Mon, 2005-01-24 at 19:24 -0500, Daniel Eischen wrote:
> On Mon, 24 Jan 2005, Joe Marcus Clarke wrote:
> 
> > On Mon, 2005-01-24 at 15:15 -0800, Julian Elischer wrote:
> > >
> > > >>
> > > >
> > > >Okay, so lobby that it gets reduced in login.conf.  Why should threads
> > > >be given less stack than processes, especially the initial thread?
> > > >
> > >
> > > because there may be 50 of them? (or maybe even 500?)
> > >
> > > Threaded programs are supposed to be aware that stack is a limited resource.
> >
> > I thought about that, but I also thought that KSEs were treated
> > similarly to processes so it wouldn't matter if each one had a full
> > allocation of stacksize?
> 
> KSE != thread
> 
> A (userland) KSE stack is very small and is just enough to
> schedule threads.  A thread stack is allocated (by default)
> off the one (and only one) process' stack.  Allocating lots
> of threads with large stacks depletes the process stack.

Ah, okay, I suspected that was the case for libc_r, but I wasn't sure if
the same thing held for all threading libraries.

What about increasing the default stack sizes as you've said you wanted
to do, plus leaving in the environment variable to aid in transition
should the stack size have to be bumped again in the future?  This would
also give us an easy way to test for stack overflows without instructing
users to rebuild their threading library.

Also, what were your planned stacksize increments?  I was hoping for
something along the lines of:

INITIAL (32-bit): 2 MB
INITIAL (64-bit) 4 MB

DEFAULT (32-bit): 1 MB
DEFAULT (64-bit): 2 MB

Joe

> 
-- 
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20050124/0bf07d5b/attachment.bin