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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
