Need some deep non-POSIX thread info (Attention you Windows folks!)
Dan Sugalski
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
Vladimir Lipsky
> 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
> 3) Find out what a thread's current stack pointer is
I would do 1), 3) this way ...
thdl = _beginthreadex(NULL, 0, thread_function, &arg, CREATE_SUSPENDED,
&thraddr);
#if defined(_X86_)
ctx.ContextFlags = CONTEXT_FULL;
#elif defined(_ALPHA_)
ctx.ContextFlags = CONTEXT_INTEGER;
#else
/* _MIPS_ and etc */
#endif
GetThreadContext(thdl, &ctx);
#if defined(_X86_)
current_stack_ptr = ctx.Esp;
#elif defined(_ALPHA_)
current_stack_ptr = ctx.IntSp;
#else
/* _MIPS_ and etc */
#endif
VirtualQuery((LPCVOID)current_stack_ptr, &mbi, sizeof(mbi));
stack_allocbase_addr = mbi.AllocationBase;
> 2) Find out how big a thread's stack is
By default, OS reserves 1 MB of memory for a thread's stack. One can specify
a different size with a linker option or a STACKSIZE statement in the .DEF
file. So it's, sort of, up to us how big a thread stack is. No problem here.
> Dan
0x4C56
Vladimir Lipsky
and at thread runtime we have to suspend thread while checking out its
registers so that to get the true values.
SuspendThread(thdl);
GetThreadContext(thdl, &ctx);
...
ResumeThread(thdl);
0x4C56
Dan Sugalski
>From: "Dan Sugalski" <d...@sidhe.org>
>
>> 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
>> 3) Find out what a thread's current stack pointer is
>
>I would do 1), 3) this way ...
[Some snippage]
Cool, thanks. I'm not sure exactly what we're going to do at the
moment, but I'm glad we can do it. Being able to temporarily pause a
thread'll be handy--that's something the POSIX thread interface won't
let you do and, while I see the point, it's really handy.
> > 2) Find out how big a thread's stack is
>
>By default, OS reserves 1 MB of memory for a thread's stack. One can specify
>a different size with a linker option or a STACKSIZE statement in the .DEF
>file. So it's, sort of, up to us how big a thread stack is. No problem here.
Yow. Unless there's a good reason for it to be that big, I think I'd
like to go with a smaller stack by default, something more like
20-30K. (Though if there are OS functions that can chew up great gobs
of stack space we can certainly go larger)
I appreciate the info, and it'll help get the generic interface for
threads nailed down.