From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Julian Graham" Newsgroups: gmane.lisp.guile.devel Subject: Re: srfi-18 requirements Date: Sun, 30 Dec 2007 15:38:25 -0500 Message-ID: <2bc5f8210712301238w583feb99w96bb77ed389eac50@mail.gmail.com> 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> <87odc88muv.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1199047125 28180 80.91.229.12 (30 Dec 2007 20:38:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Dec 2007 20:38:45 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel@gnu.org To: "Neil Jerram" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Dec 30 21:39:00 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 1J94vx-00007S-Pg for guile-devel@m.gmane.org; Sun, 30 Dec 2007 21:38:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J94vc-0007ge-A3 for guile-devel@m.gmane.org; Sun, 30 Dec 2007 15:38:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J94vW-0007dS-MS for guile-devel@gnu.org; Sun, 30 Dec 2007 15:38:30 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J94vW-0007co-3Z for guile-devel@gnu.org; Sun, 30 Dec 2007 15:38:30 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J94vW-0007cd-0H for guile-devel@gnu.org; Sun, 30 Dec 2007 15:38:30 -0500 Original-Received: from fk-out-0910.google.com ([209.85.128.185]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J94vV-0000Lq-JD for guile-devel@gnu.org; Sun, 30 Dec 2007 15:38:29 -0500 Original-Received: by fk-out-0910.google.com with SMTP id 26so5251313fkx.10 for ; Sun, 30 Dec 2007 12:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YH18NxbqBAbuxhoW6bSb7G54YNghLFg7dzgv6uyvXCU=; b=F65a7Y6cnkrsC/y4LrOkowuiPRP+znxKxh3G6vkObOlJhCJrtd9EJ1lQyvV6O74GLeo5BWciUFRAU8yip130bknWzvq+ygjm1T9fP9DhD9uQGXtfPxl5KIOG/UyiIEJQguab3kcmAKYBnQ12XIqmFr62ycXwO548pAFIpg8d3r0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GBjeXPe6WbxidoyXTAuDD6X104XA8s37oyHha02vjjsLkleg09XrROEgn0CLcJ2vOl+F+EfWCZGEmPH78XuoPK5CCRFtUTid7EvfOZ6NyM+GbmNSZxslGnIGFoxZTMoQ9d70sjP0DwiCPCOOBEc3fEs2NaaL2IwjRDPkLRXH4VQ= Original-Received: by 10.82.146.14 with SMTP id t14mr20857476bud.9.1199047105631; Sun, 30 Dec 2007 12:38:25 -0800 (PST) Original-Received: by 10.82.176.13 with HTTP; Sun, 30 Dec 2007 12:38:25 -0800 (PST) In-Reply-To: <87odc88muv.fsf@ossau.uklinux.net> Content-Disposition: inline X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:6948 Archived-At: Hi Neil, Thanks for your comments. > 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? Sure. > 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? Yes, that's right. The purpose of the C component of the patch is to add to and extend Guile's core API in a way that is consistent with the existing core code (in terms of function names and arguments) but which allows the Scheme component of the patch to cleanly (i.e, relying mainly on primitive functions) implement SRFI-18 on top of it. > What then happens if a SRFI-18 procedure is called on a > non-SRFI-18-created thread, or vice versa? Nothing significantly different, in most cases. The main differences between threads created by core code and by SRFI-18's make-thread are in the way they start up (SRFI-18 threads must be explicitly started) and in the way exceptions are handled (SRFI-18 threads have a top-level exception handler that marks exceptions for rethrow in joining threads). As far as I can see, the worst case would be a lost exception thrown from an SRFI-18 call in a non-SRFI-18 thread -- but that's Guile's existing behavior. > (Is there already a list somewhere of differences between existing > and SRFI-18 behaviour? That would help my understanding, at > least.) I can prepare one. > 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. Agreed, except that in a few cases the patch introduces changes to existing behaviors that were previously "undefined" -- for example, unlocking a mutex from outside the thread that originally locked it. SRFI-18 addresses this explicitly and describes the expected behavior. > Why is Thread 2 still in the critical section when it calls > make_jmpbuf? That strikes me as the problem here. I should've been clearer -- SCM_CRITICAL_SECTION_START occurs *within* make_jmpbuf. As to why this is necessary, I must confess I'm not well enough versed in the particulars of Guile's jmp and async code... it may indeed be anachronistic, but it'll take me some time to trace through things to see if that's the case. Anyone out there happen to know? > See e.g. handling of scm_srfi1_map in srfi/srfi-1.c. Would that work > for the SRFI-18 extensions? I take it you're talking about "map" and "map-in-order" both using scm_srfi1_map via SCM_GPROC and SCM_REGISTER_PROC, respectively? Yes, that looks feasible. > 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. Not necessarily, given how close the core behavior already is to SRFI-18 (unless I'm misunderstanding) -- that is to say, loading the SRFI-18 module doesn't change the behavior of any existing thread functions in either Scheme or C. Even in cases where new SRFI-18-supporting functions have been added that have Scheme exposure (e.g., scm_lock_mutex_timed -> "lock-mutex-timed"), SRFI-18 wraps them in new names that don't conflict with existing bindings ("mutex-unlock!"). Shall I go ahead and prepare bugfix patches against 1.8.x and HEAD for the non-SRFI-18 stuff? Regards, Julian _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel