Subject: Re: why python+pth?
To: Nathan J. Williams <firstname.lastname@example.org>
From: Christian Limpach <email@example.com>
Date: 11/19/2003 13:03:36
From: "Nathan J. Williams" <firstname.lastname@example.org>
> Christian Limpach <email@example.com> 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...