Re: hacking on 1.7 threads

[Julian Graham]

Hi Mikael, 
  Yes, I eventually realized on my own that extending the mark
function for threads was the way to go, and I'm currently trying to
address the very synchronization issues you mention below.  I'll have
a look at that document, too.  Thanks!


Julian


On Sun, 24 Oct 2004 11:29:06 +0200, Mikael Djurfeldt
<address@hidden> wrote:
> Julian Graham <address@hidden> writes:
> 
> > That is, if I'm storing a list SCM in an scm_thread struct that's
> > allocated on the heap, and I cons stuff onto it, do I have to do
> > anything special to prevent the GC from collecting the SCM contents
> > of the struct?
> 
> Yes.  As Rob already has explained, any Scheme object stored in a data
> structure allocated outside the stack must be explicitly protected.
> 
> The way to do it in this case is to add a line in
> threads.c:thread_mark:
> 
> static SCM
> thread_mark (SCM obj)
> {
>   scm_thread *t = SCM_THREAD_DATA (obj);
>   scm_gc_mark (t->result);
>   scm_gc_mark (t->cancellation_handler_list); /* <--- */
>   return t->root->handle; /* mark root-state of this thread */
> }
> 
> Note, though, that this is the easy part.  I do expect that there also
> could arise nasty complications having to do with the order in which
> things are done at cancellation.  It's for example important that the
> scm_thread data structure isn't deallocated before the handlers are
> invoked.  It's also important that the GC is still aware of the thread
> at that point in time.  It's important that the thread *is* properly
> deallocated *after* the handlers have run---that kind of stuff.  But
> maybe there's no problem at all.