Re: hacking on 1.7 threads

[Julian Graham]

Okay, I've worked out the files.  But now I've got a different problem
with my implementation, and maybe you guys can give me some insight
because I've got some experience writing code *with* Guile, but none
debugging Guile itself.

The way my thread cancellation patch works is that I add an SCM member
to the scm_thread struct.  The SCM is a list of expressions to be
evaluated if the thread is cancelled.  I use the native threading
library's cancellation / cleanup handler mechanism -- in this case,
pthread_cancel, pthread_cleanup_push / pop.  So in fact, there is only
one cleanup handler, which evaluates each expression in the list of
Scheme "cleanup expressions."  The Scheme cleanup pushing and popping
functions I provide simply push and pop expressions onto and off of
the SCM list stored in the scm_thread struct.

My problem is that when I call cancel on a running thread and the
cancellation handler that's supposed to evaluate the contents of the
cleanup expression list runs, the list no longer contains what I
expect; in fact, it's not a list at all any more sometimes.  Something
happens in between where my cleanup expression pushing function gets
called (I check the list before and after pushing an expression onto
it) and where the cancellation handler gets called.  Could it be some
kind of garbage-collection thing?  My understanding of garbage
collection of SCMs in C code is not wonderful; do I have to do
anything further than scm_remember_upto_here_1 to make sure that the
garbage collector doesn't delete stack data that I use for longer than
its scope?  What about heap data?  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?  Does the fact that it's a
list (i.e., a chain of pairs) that I'm trying to protect make a
difference?  (I'm assuming that if the head element gets marked, all
the CDRs will get marked as well.)


Thanks,
Julian


On Tue, 19 Oct 2004 09:46:20 -0400, Julian Graham <address@hidden> wrote:
> Hi guys,
>   I'm trying to debug this thread cancellation patch I wrote against
> CVS HEAD, and I'm having a bit of trouble sorting out the source
> files.
>   The first thing I noticed was that it didn't look like a new Pthread
> was being created when I called call-with-new-thread from my Scheme
> code; after looking in the Makefile, it looks like none of
> threads-plugin.c, pthread-threads.c, and null-threads.c are getting
> compiled -- they're all in this list of EXTRA_DIST files.  Am I
> missing something?  How can the new threads system get used if it's
> not even getting built in?
>   Also, I noticed that coop-pthreads.c has a more recent CVS
> modification time (if I'm reading the CVS log right) than threads.c,
> even though the comments in both files lead me to believe that
> threads.c is the future.  Am I missing something?  The way I figured
> the new threading stuff was going to work was:
> 
>   - threads.c: implements generic thread-manipulation stuff, like
> creating and freeing the scm_thread structure, etc.
>   - threads-plugin.c, [threading-library]-threads.h: defines some
> wrappers for the actual threading-library functions, such as the
> scm_i_plugin_* functions.
>   - [threading-library]-threads.c: contains any functions that need to
> be implemented using the actual API from the chosen threading library.
>  This is probably only a few things in most cases, since
> threads-plugin maps the plugin functions directly to threading API
> calls -- e.g., scm_i_plugin_thread_self -> pthread_self.
> 
>   Any corrections?
> 
> Cheers,
> Julian
>