"Nathan J. Williams" <nathanw@wasabisystems.com> writes:
>> 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.

Yes, but there is a subset for which it appears to be very important.

> 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).

I thought that some segment register (FS?) was explicitly used by
Microsoft in their ABI for threads and that our ABI could deal with
that already.

If that's the case, we could allow varying stack sizes on those
architectures that had a register available....

>> 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).

Does the stack size typically get set while we're still running only
with one thread?

-- 
Perry E. Metzger		perry@piermont.com