From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 requirements Date: Sun, 30 Dec 2007 11:04:40 +0000 Message-ID: <87odc88muv.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <87lka8pvv3.fsf@laas.fr> <2bc5f8210710120831q5c90dcfes930595fa3eb16a77@mail.gmail.com> <2bc5f8210710151526t6345200ao997988c1877e8cce@mail.gmail.com> <4713EB20.3080608@member.fsf.org> <2bc5f8210710151547l5e245ed1ucaf07e9006e95387@mail.gmail.com> <2bc5f8210710290737j32fe7b1s86aaa7e084bb69b6@mail.gmail.com> <87ve7mmdpl.fsf@chbouib.org> <2bc5f8210712172030h101f71e2w95265d138ffdb2a8@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199012745 4404 80.91.229.12 (30 Dec 2007 11:05:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Dec 2007 11:05:45 +0000 (UTC) Cc: =?iso-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: "Julian Graham" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 30 12:05:59 2007 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J8vyi-00087N-G4 for guile-devel@m.gmane.org; Sun, 30 Dec 2007 12:05:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8vyM-0008WC-Vh for guile-devel@m.gmane.org; Sun, 30 Dec 2007 06:04:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8vyL-0008W7-0y for guile-devel@gnu.org; Sun, 30 Dec 2007 06:04:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8vyK-0008Vj-Ca for guile-devel@gnu.org; Sun, 30 Dec 2007 06:04:48 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8vyJ-0008Vc-SY for guile-devel@gnu.org; Sun, 30 Dec 2007 06:04:48 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J8vyF-0008TY-Hv; Sun, 30 Dec 2007 06:04:43 -0500 Original-Received: from arudy (host86-145-183-175.range86-145.btcentralplus.com [86.145.183.175]) by mail3.uklinux.net (Postfix) with ESMTP id 2B4AF1F6744; Sun, 30 Dec 2007 11:04:41 +0000 (GMT) Original-Received: from laruns (unknown [192.168.0.10]) by arudy (Postfix) with ESMTP id 5A4B83800A; Sun, 30 Dec 2007 11:04:40 +0000 (GMT) In-Reply-To: <2bc5f8210712172030h101f71e2w95265d138ffdb2a8@mail.gmail.com> (Julian Graham's message of "Mon, 17 Dec 2007 23:30:46 -0500") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:6947 Archived-At: "Julian Graham" writes: > Hi everyone, > > Thanks for your comments and patience. I've attached a new version of > my SRFI-18 patch which I hope addresses the stuff that Ludovic raised. I have some general comments. I'm sorry for not coming up with these earlier. 1. Some of your changes are bug fixes for the existing thread code, and not dependent on SRFI-18, so we should apply these to 1.8.x as well as to HEAD. Can you pull these out into a separate patch? 2. I don't think it's clear what the overall effect of the SRFI-18 enhancement will be. Is it your intention that Guile will then implement SRFI-18 behaviour by default? Or that it will be an option, alongside the existing thread behaviour? Based on the current patch, I think you intend the latter, and that the choice of existing/SRFI-18 behaviour is made by what procedures the calling code uses, which in turn depends on whether that code has done (use-modules (srfi srfi-18)). Right? What then happens if a SRFI-18 procedure is called on a non-SRFI-18-created thread, or vice versa? (Is there already a list somewhere of differences between existing and SRFI-18 behaviour? That would help my understanding, at least.) 3. I think it's important that existing thread behaviour continues to work exactly as it does before your enhancement (modulo bug fixes, of course), so I'd prefer if the code changes could be structured in such as way as to make it obvious that this will be the case. Perhaps this is impossible, in which case we have to rely on review, but if there is anything that could be done here, that would be good. I haven't commented on the patch in detail, because it may change depending on discussion of the above points. I have a few points on the text below though. >> I don't quite get this one. Could you illustrate the problem >> step-by-step with a simple scenario? >> >> The value of HANDLER in `scm_spawn_thread ()' doesn't seem to affect >> critical-section locking. > > Maybe I should have said the problem lies in really_spawn() -- if > data->handler is non-NULL, then really_spawn() enters the thread's > body via scm_internal_catch() instead of directly. > scm_internal_catch() calls scm_c_catch(), which calls make_jmpbuf(), > which enters a critical section, leading to the deadlock. Here's the > sequence of events that I was experiencing (surprisingly often): > > Thread 1, in guile-mode (heap mutex locked) launches Thread 2 > Thread 2 enters a critical section, locking the critical section mutex > Thread 1, as part of expression evaluation in eval.i.c, attempts to > lock the critical section and blocks > Thread 2, as part of make_jmpbuf, calls SCM_NEWSMOB2, leading to a > call to scm_double_cell, which causes a GC. Thread 2 attempts to lock > the heap mutex of all executing threads, but Thread 1's heap mutex > will never be unlocked Why is Thread 2 still in the critical section when it calls make_jmpbuf? That strikes me as the problem here. > I've subsequently discovered and fixed a separate (quasi-) deadlock, > also-preexisting, this time related to a lack of thread safety > surrounding the usage of scm_thread_go_to_sleep -- in short, there can > be a race on the value of scm_thread_go_to_sleep such that a thread > can continue to enter and leave guile-mode even while > scm_i_thread_put_to_sleep is trying to put it to sleep for GC. The > fix is to require that threads hold the thread_admin_mutex while > locking their heap_mutexes in scm_enter_guile, so that they don't > inadvertantly re-enter guile-mode during a GC attempt. I can give you > an example if you'd like. Nice fix. >> +SCM_DEFINE (scm_join_thread_timed, "join-thread", 1, 2, 0, >> >> Scheme/C name mismatch. I believe it effectively hides the first >> `join-thread', right? > > Yes, I put it there to override the binding of join-thread. Is that a > problem? I do it several other places, too. I wasn't sure how else to > maintain binary compatibility for users of scm_join_thread while > extending the functionality of the Scheme 'join-thread' function. > Would it be better if I removed the first SCM_DEFINE (the one that > refers to scm_join_thread()) and replaced it with a normal function > declaration for scm_join_thread()? See e.g. handling of scm_srfi1_map in srfi/srfi-1.c. Would that work for the SRFI-18 extensions? Note that this would imply a separate SRFI-18 library, which gets loaded when the srfi-18 module is first used. So clearly this is related to the points above code structure and separating existing and SRFI-18 behaviour. >>> +"Suspend execution of the calling thread until the target @var{thread} " >> >> Indenting would be nicer. > > You mean indenting the doc strings so that they line up with the > parentheses? None of the other functions do this. (And is this > documentation actually used to generate anything?) In theory, yes: see doc/maint/docstring.el. I haven't actually done this for years, but I believe it should still work. >> Type-checking overhead may become a concern if we are to convert values >> often, e.g., once after every timed-join trial. OTOH, it's good to have >> good error reporting. > > So... do you have a ruling, one way or the other? For what it's > worth, my opinion is that API exposed to the user must always feature > input-checking, but I defer to your maintainer wisdom. I think the check-arg-type calls are messy, but I'm not that much bothered. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel