"Perry E.Metzger" <perry@piermont.com> writes:

> Christian Limpach <chris@pin.lu> writes:
> > On Tue, 18 Nov 2003 10:14:47 +0100 Marc Recht <recht@netbsd.org> wrote:
> >
> >> > I know of no other systems where this is necessary.
> >> 
> >> AFAIK the other systems implement "pthread_attr_setstacksize".
> >
> > well, we have "pthread_attr_setstacksize" but it doesn't change the
> > stack size.  This is probably because we only support one stack size for
> > all stacks.
> 
> Can we fix that? This will improve things for a number of
> applications.

If it was easy I would have done it long ago. Most applications don't
know what the stack size is and don't care.

Thread identification is presently based on stack location, and is
woven pretty tightly into how libpthread works. Changing stack sizes
requires an overhaul of the thread-ID, and presents some tricky
data-structure issues, since locking has thread-ID as a prerequisite.

On some architectures (alpha, sparc, maybe ppc), there's a register
avaliable for thread storage; I have some work in progress to use that
instead of stack identification on those systems. On others (mips,
arm, vax, sh) no such register is avaliable, so some kind of
stack-based ID is still needed (i386 is really more like the latter
case, but there are some possible segment register kluges).

        - Nathan

> How is pthread_attr_setstacksize typically used? We might be able to
> optimize if we typically have only a small number of different stack
> sizes...

It's used pretty haphazardly. Most uses are an application that thinks
it needs a "big" stack setting the stack size to be some number of
megabytes. BIND 9 is the only application I've seen so far that tries
to set the stack size to something small (64k).

        - Nathan