From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Julian Graham Newsgroups: gmane.lisp.guile.devel Subject: Re: hacking on 1.7 threads Date: Sat, 23 Oct 2004 19:55:57 -0400 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <2bc5f821041023165523f40bc2@mail.gmail.com> References: <2bc5f82104101906465a92d975@mail.gmail.com> Reply-To: Julian Graham NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1098575788 506 80.91.229.6 (23 Oct 2004 23:56:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 23 Oct 2004 23:56:28 +0000 (UTC) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Oct 24 01:56:23 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CLVkF-0001jq-00 for ; Sun, 24 Oct 2004 01:56:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CLVro-0005l4-C0 for guile-devel@m.gmane.org; Sat, 23 Oct 2004 20:04:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CLVrg-0005kz-DR for guile-devel@gnu.org; Sat, 23 Oct 2004 20:04:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CLVrf-0005kn-Tj for guile-devel@gnu.org; Sat, 23 Oct 2004 20:04:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CLVrf-0005kk-Q9 for guile-devel@gnu.org; Sat, 23 Oct 2004 20:04:03 -0400 Original-Received: from [64.233.170.207] (helo=rproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CLVjq-0003cV-HK for guile-devel@gnu.org; Sat, 23 Oct 2004 19:55:58 -0400 Original-Received: by rproxy.gmail.com with SMTP id 74so250052rnl for ; Sat, 23 Oct 2004 16:55:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Pg97zOJxyVohPYDyEStcEjOh6g81uJXVnHQzD72fErce0958RIYogfyGigi2UBjbHxD7niQ25Qh2w6Bu/BQw5foaQGQqhE+zaR+Gab0NhbThvdooEpYIbQ/MCkFy+D9jmZSFLQYQTlPj2cYEE0U61UNo+AXaaaMntvLXVGdXWLE= Original-Received: by 10.38.208.52 with SMTP id f52mr285256rng; Sat, 23 Oct 2004 16:55:57 -0700 (PDT) Original-Received: by 10.38.208.5 with HTTP; Sat, 23 Oct 2004 16:55:57 -0700 (PDT) Original-To: guile-devel@gnu.org In-Reply-To: <2bc5f82104101906465a92d975@mail.gmail.com> X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:4287 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4287 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 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 > _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel