As stated already, this (and possibly other thread) test(s) can't succeed as long as Win32 has no event loop that passes the terminate event on to the running interpreter.
If you read the output that Jerry sent earlier, you would have seen that the thread doesn't ever reach to the print"thread\n" opcode, not to tell about push P6, P2
Run is_pmc_ptr(interp, pmc) or check the involved pmc arenas to verify this assumption.
This doesn't happen on my PC; all the first thread's pmc's are allocted whithin [arena_start;arena_end], the active pmc's number is equal to 457. This is why I asked him to sent me output with the -d option on. I want to see how many pmc pool arenas are allocated by the first thread.
0x7d5a08 - 0x637dc8 == ~1.6 Mb Does Parrot have that huge arenas?
parrot (r8016): no change. hangs w/98% cpu. here's the -t output:
parrot -t test_b.pasm0 find_global P5, "_foo" - P5=SArray=PMC(0x7d5a50),
3 new P2, 18 - P2=PMCNULL,
6 find_method P0, P2, "thread3" - P0=PMCNULL,
P2=ParrotThread=PMC(0x7d5a08),
10 new P6, 54 - P6=PMCNULL,
13 set I3, 2 - I3=1,
16 invoke
17 set I5, P2 - I5=3, P2=ParrotThread=3DPMC(0x7d5a08)
20 getinterp P2 - P2=ParrotThread=PMC(0x7d5a08)
22 find_method P0, P2, "detach" - P0=NCI=PMC(0x638620), P2=ParrotInterpr=PMC(0x637dc8)
