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: Tue, 08 Jan 2008 23:41:33 +0000 Message-ID: <87lk6z3mxe.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <2bc5f8210710151547l5e245ed1ucaf07e9006e95387@mail.gmail.com> <2bc5f8210710290737j32fe7b1s86aaa7e084bb69b6@mail.gmail.com> <87ve7mmdpl.fsf@chbouib.org> <2bc5f8210712172030h101f71e2w95265d138ffdb2a8@mail.gmail.com> <87odc88muv.fsf@ossau.uklinux.net> <2bc5f8210712301238w583feb99w96bb77ed389eac50@mail.gmail.com> <87fxxh8isb.fsf@ossau.uklinux.net> <2bc5f8210801032101x33db423ak7bf7950c378ae27e@mail.gmail.com> <87abnldsg5.fsf@ossau.uklinux.net> <2bc5f8210801061341o5a8b060fm3e80d6b9cb8eb4d6@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 1199835712 18918 80.91.229.12 (8 Jan 2008 23:41:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Jan 2008 23:41:52 +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 Wed Jan 09 00:42:11 2008 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 1JCO59-00049i-FY for guile-devel@m.gmane.org; Wed, 09 Jan 2008 00:42:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCO4m-0007uN-Bl for guile-devel@m.gmane.org; Tue, 08 Jan 2008 18:41:44 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JCO4i-0007pJ-Pp for guile-devel@gnu.org; Tue, 08 Jan 2008 18:41:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JCO4h-0007nk-SK for guile-devel@gnu.org; Tue, 08 Jan 2008 18:41:40 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCO4h-0007nM-NA for guile-devel@gnu.org; Tue, 08 Jan 2008 18:41:39 -0500 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JCO4d-0006rW-Nk; Tue, 08 Jan 2008 18:41:36 -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 AC3F11F668D; Tue, 8 Jan 2008 23:41:34 +0000 (GMT) Original-Received: from laruns (unknown [192.168.0.10]) by arudy (Postfix) with ESMTP id F0DA83800A; Tue, 8 Jan 2008 23:41:33 +0000 (GMT) In-Reply-To: <2bc5f8210801061341o5a8b060fm3e80d6b9cb8eb4d6@mail.gmail.com> (Julian Graham's message of "Sun, 6 Jan 2008 16:41:34 -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:6955 Archived-At: "Julian Graham" writes: > With regard to your comments about the rest of the patch, agreed, except: > > Given the similarities between the existing Guile threading code and > SRFI-18, what level of comptability between these two domains will be > supported? For example, SRFI-18 specifies that threads waiting on a > mutex held by a thread that exits should be notified of the exit and > that one of them will then be able to lock that mutex. Given the > changes you describe below, will this behavior only work if all the > components in the user's code were created using the SRFI-18 API? No. I think that what SRFI-18 says about abandoned mutexes makes good sense for threads in general, and also that it is generally good to make Guile's behaviour here better defined. So I'm happy for what SRFI-18 says about abandoned mutexes to apply equally to both core and SRFI-18 threads. > What about a thread that calls SRFI-18's thread-join function on a > non-SRFI-18 thread that died with an exception? Well, according to the picture of my previous email - in which it is the job of the thread-handler (as specified to call-with-new-thread) to preserve the death exception - I think it is clear that a non-SRFI-18 thread would _not_ save off its death exception in the way that SRFI-18 says, and hence that this exception will _not_ be available when another thread (whether SRFI-18 or not) does a join-thread on the terminated thread. The implication is that if you want this detail of the SRFI-18 semantics, both of the threads involved must be SRFI-18 threads. That all seems fine to me. I'm happy with that implication, and I think the overall picture is clear. > (Are you sure you > don't want thread exceptions in the core? I feel like join-thread > isn't really "complete" without them...) Yes, I feel pretty sure about this. SRFI-18's edicts in this area do not feel obviously correct and generally applicable in the same way as what it says about abandoned mutexes (for example). Therefore, if we can factor this out of the core - and it appears that we can - I think we should do so. >> Finally, there are quite a few spurious changes (or perhaps just that >> I don't understand yet) in patch: whitespace, line break and docstring >> changes. Can you revert all these, as they only confuse the overall >> picture? > > This may have just been stuff that Ludovic asked me to clean up (or > that I just cleaned up ad-hoc). It can all go. Sorry if we've been giving opposing steers. I think in a tricky patch like this one, it's best to minimize distractions; hence I recommend following GCS for any new or changed code, but not including janitorial changes (even to conform to GCS) to code that would not otherwise have changed. (Purely janitorial changes are fine per se, but should be separate.) >> I'm sorry that I'm asking for some significant changes here, but I >> hope that you'll agree that they make the enhancement clearer, and in >> particular that it is a good thing to reduce the changes that we need >> to make to the C code. Please let me know what you think. > > Not a problem. Thank you for taking the time to all this analysis. > What's the next thing you'd like me to submit? How about (2), the > enhancement patch for timed joins? Do you mean that timed joins is separable from the rest of the C enhancements (e.g. timed mutex locking)? If so, timed joins on its own would be great. If not (which I was expecting, although without too much thought), it's fine for the next patch to be all of the C code enhancements. Regards, Neil