"Nathan J. Williams" <nathanw@wasabisystems.com> writes:
>> Yes, but there is a subset for which it appears to be very important.
>
> It's a smaller subset than you think. Most apps that believe they need
> to change the stack size are wrong. So far, Python is the only
> application I know of where there is a legitimate need.

That's not entirely the point. The problem is people don't want to
have to rewrite their apps for NetBSD. Even if it is only 50
applications out of 2000 it is still an issue, especially if someone
absolutely needs that particular application.

In the end, sadly, POSIX doesn't count as much for compatibility as
being compatible with other Unixes. :(

>> > 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.
>
> Segment regesters are funny beasts; you can't just load arbitrary
> values into them. The trick is not so much using the register in
> userland as setting up the infrastructure that lets you install a
> useful set of values in the register.
>
> Besides, that just moves i386 into the non-stack-ID camp. I actually
> care about the general problem.

ARM, SuperH and Vax have a lot of registers available. We could find a
way to do something there.


-- 
Perry E. Metzger		perry@piermont.com