Subject: Re: why python+pth?
To: Nathan J. Williams <>
From: Christian Limpach <>
List: tech-pkg
Date: 11/19/2003 13:03:36
From: "Nathan J. Williams" <>
> Christian Limpach <> 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
> > 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...