[plt-scheme] embedded MzScheme not started on main thread

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Mon Sep 2 21:59:16 EDT 2002

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?  


> 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.


Posted on the users mailing list.