It's not as simple as that.
I've changed the test program such that two threads are created, and
they "exist together" :
t1 = CreateThread(NULL, THREAD_STACK_SIZE,
&thread,
NULL,
STACK_SIZE_PARAM_IS_A_RESERVATION,
NULL);
t2 = CreateThread(NULL, THREAD_STACK_SIZE,
&thread,
NULL,
STACK_SIZE_PARAM_IS_A_RESERVATION,
NULL);
WaitForSingleObject(t1, 10000);
WaitForSingleObject(t2, 10000);
Do createthread/wait/createthread/wait and you'll see that both threads
reuse the same address space. Not what we wanted to test.
Anyway, with the code above, and THREAD_STACK_SIZE equal to 0x0200000 in
one case, or 0x0100000 in the other, these are the outputs :
\network\x86> test3
Main 2C01FB74
Deeper 2C267B24
Deeper 2C467B24
\network\x86> test3
Main 2E01FB74
Deeper 2E167B24
Deeper 2E267B24
\network\x86>
The difference between the "Deeper" lines is exactly the amount of stack
requested.
The difference between the Main number and the first Deeper number is
probably the sum of the sizes of some stack and some heap segment.
Danny
On Tue, 2009-06-09 at 22:11 +0900, Pawel Veselov wrote:
> This is not particularly nice...
> The addresses are over a megabyte apart.
> Which most likely means that the stack addresses for the new threads
> are allocated in the newly created regions.
>
> My big question to M$ would be -- if this is the case, then why the main
> thread is limited to 64k, when the total stack segment defaults to
> 1Mb? What is the purpose of modifying the stack segment size by
> the linker, etc.
>
> On Tue, Jun 9, 2009 at 2:39 PM, Danny Backx<danny.ba...@scarlet.be> wrote:
> > \network\x86> test3
> > Main 2001FB78
> > Deeper 20167B24
> >
> > In my program, with two statements added in obvious places.
> >
> > Danny
> >
> >
> > On Tue, 2009-06-09 at 12:24 +0900, Pawel Veselov wrote:
> >> I mean, something like this, but with Windows thread calls.
> >> (I can't run any cegcc code at the moment).
> >> Just wondering where would the stack addresses be for new
> >> threads.
> >>
> >> Thanks!
> >> Pawel.
> >>
> >> [pv230...@druid]~/cprog$ cat stt.c
> >> #include <stdio.h>
> >> #include <pthread.h>
> >>
> >> static void prt_stk() {
> >> int i;
> >> fprintf(stdout, "my stack is near %p\n", &i);
> >> }
> >>
> >> static void* t_start(void * n) {
> >> prt_stk();
> >> return 0;
> >> }
> >>
> >> int main(int argc, char ** argv) {
> >>
> >> pthread_t t1;
> >> pthread_t t2;
> >> void * n;
> >> prt_stk();
> >> pthread_create(&t1, 0, t_start, 0);
> >> pthread_create(&t2, 0, t_start, 0);
> >>
> >> pthread_join(t1, &n);
> >> pthread_join(t2, &n);
> >> return 0;
> >>
> >> }
> >>
> >> On Tue, Jun 9, 2009 at 3:06 AM, Danny Backx<danny.ba...@scarlet.be> wrote:
> >> > You probably mean something like the attached test. What do you want to
> >> > know about it ? I can run it on x86 and on ARM.
> >> >
> >> > Danny
> >> >
> >> > On Mon, 2009-06-08 at 18:16 +0900, Pawel Veselov wrote:
> >> >> Should the prologue code be rewritten to have
> >> >> a thread created before main() is called?
> >> >>
> >> >> Also, it'd be interesting to see where are the
> >> >> new thread stacks are created, I've looked
> >> >> at how other OSes do that, and they just
> >> >> simply create a new segment. Since m$ seem
> >> >> to not give you stack segment for the stack
> >> >> completely, it should allocate thread stacks
> >> >> somewhere in that stack segment.
> >> >>
> >> >>
> >> >> On Mon, Jun 8, 2009 at 6:06 PM, Johnny Willemsen <jwillem...@remedy.nl>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> >> gcc code may user more of the stack than whatever code that msvc
> >> >> >> produces, thus
> >> >> >> dipping into the red zone more often. So far, I don't see how the 64k
> >> >> >> limit of the
> >> >> >> stack on the main thread can be avoided at all..
> >> >> >
> >> >> > The only option I see (which also Danny proposed) is to create a
> >> >> > worker thread, use that as main thread, then we can control the stack
> >> >> > size.
> >> >> >
> >> >> > I will rewrite a few tests at our side to get some objects from the
> >> >> > heap instead of from the stack.
> >> >> >
> >> >> > Johnny
> >> >> >
> >> >> >
> >> >>
> >> > --
> >> > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
> >> >
> >>
> >>
> >>
> > --
> > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
> >
> >
>
>
>
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
