[plt-scheme] embedded MzScheme not started on main thread
Thanks for the info. I found the problem. When
I switched from building my code into a static
library to building it into a DLL, the DllMain
function from the gc project was executing and
initializing the gc before my code had a chance
to set the GC_USE_REGISTERED_STATICS flag.
Scott
9/2/2002 7:59:16 PM, Matthew Flatt
<mflatt at cs.utah.edu> wrote:
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/pl
t-scheme
>
>At Mon, 26 Aug 2002 17:27:18 -0600, Scott
Walters wrote:
>> I'm not really very knowledgeable about how
the
>> gc works but it seems like I would have to set
>> the stack bottom for the MzScheme initializing
>> thread to the address of a procedure variable
>> inside a function that would not be returned
from
>> until the thread died. Is this right?
>
>Right.
>
>> If it is,
>> I'm not sure how it can work in my setup since
>> the Java servlet container controls the code
that
>> the thread initially executes so I don't
really
>> know where the stack bottom is by the time my
>> Java code is invoked. Do you know of a way I
can
>> find out for Win32?
>
>It doesn't have to be the actual stack bottom.
Just something "below"
>the part of the stack used for Scheme code.
>
>> Also, does the gc store a stack bottom for all
>> threads. I assume it must but I guess this is
>> handled by the MzScheme code. Does this affect
>> what I have to do to set the stack bottom?
>
>There's one stack bottom, since MzScheme will
work with only one thread
>at any given time.
>
>> First, I tried starting a C thread that sets
>> GC_stackbottom to the address of a procedure
>> variable, initializes scheme and then waits
>> indefinitely.
>
>That should have worked, so I think something
else is going wrong.
>
>> When this didn't work, I tried
>> setting the GC_USE_DLL compile flag on the gc
>> since this is how it's ultimately ending up
even
>> though the dll I build is statically linking
>> MzScheme. Is this correct?
>
>I think you don't want GC_USE_DLL, but I forget
the subtleties of v103.
>
>> It bombs in the last line of the
>> following function because the hhdr variable
is
>> null. Does this suggest anything?
>>
>> GC_bool GC_is_marked(p)
>> ptr_t p;
>> {
>> register struct hblk *h = HBLKPTR(p);
>> register hdr * hhdr = HDR(h);
>> register int word_no = (word *)p - (word
*)h;
>>
>> return(mark_bit_from_hdr(hhdr, word_no));
>> }
>
>Offhand, I'd guess that the GC's own data
structures are getting
>collected, which might mean that the GC is
having trouble finding the
>address of static variables.
>
>In other words, the problem may have less to do
with finding the stack
>than finding static variables.
>
>Matthew
>
>
>