Well... it's time to start digging into threads more seriously, which
Leo's been starting to do. At the moment I'm leaning towards all
threads in a thread group sharing string and PMC arenas, and memory
pools, as it makes life very much easier in some ways, except...

The DOD. And the GC, though that'll be less of an issue if we swap in
a non-moving collector when we go multithreaded.

The biggest issue with sharing pools is dealing with the system
stack, as we'll now have multiple stacks, one for each thread. That
makes finding the stacks and walking them somewhat problematic.

Now, for POSIX threads, which the various Unices and VMS use, we can
handle this without much of a problem. There's sufficient information
available, and sufficient calls handy, to get a handle on a thread's
stack. (Though we may have to do it at thread creation time. Still,
it's doable) However... there's the pesky issue of non-POSIX thread
implementations, pesky mainly because I have *no* idea what they do,
and by the time I get up to speed with Windows threads I think it's
safe to say that it'll be too darned late.

So, could someone with some windows experience go digging and find
out how one would:

1) Find the address of the base of a thread's stack
2) Find out how big a thread's stack is
3) Find out what a thread's current stack pointer is

If we have to do some of this at thread creation time (i.e. creating
a thread and handing it a chunk of memory X bytes long to use as its
stack) that's fine, and if we can't get some of this info (#3 is
definitely problematic) well... we can cope. (This is definitely one
of those times where I really want to get a handle on the output of
the C compiler and its boilerplate. I take this as a bad sign :)
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk