From: "Nathan J. Williams" <nathanw@wasabisystems.com>
> Christian Limpach <chris@pin.lu> writes:
>
> > If we wanted to support different stack sizes, we could use a tree to
> > find the thread.  We'd take a performance hit searching the tree, so
we'd
> > only use this if there are any stacks with a different size.  Other
> > suggestions are welcome...
>
> There's some definite trickiness in how to update such a tree - a
> thread that wants to look itself up in the tree can't use locks,
> because it has to identify itself to use locks, but the tree shouldn't
> change out from under it.

Ah yes, maybe the following would work then:  we keep a bytemap of the
address space indicating what size of stack is used in this area of the
address space.  If the granularity is 2MB, then we'd need a 512 byte large
map for a 1G address space.  For smaller stacks, we'd then only put same
sized stacks in a 2MB area.  The SP->thread mapping would still use masking
of the SP, the mask would be chosen through the value from the map.  A stack
would always use as much address space as the next higher power of 2.  For
much larger address spaces, I'd hope that the processors-ABI provides a
thread register and this code won't be needed, if not we can increase the
granularity.  Since the map only gets updated when a new stack is allocated
in a new area, we don't need locking.  This would also seem faster than a
tree based approach...

    christian