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: Wed, 09 Apr 2008 22:29:38 +0100 Message-ID: <87tziaogxp.fsf@ossau.uklinux.net> References: <2bc5f8210710101854m1254160ei451026182b87e767@mail.gmail.com> <87ir0e1yka.fsf@ossau.uklinux.net> <2bc5f8210802241017o46468365j33c329a069d96d33@mail.gmail.com> <873ariaq82.fsf@ossau.uklinux.net> <2bc5f8210803011156i3bfb976bsda2a7902654ba3a6@mail.gmail.com> <87bq5pb2ea.fsf@ossau.uklinux.net> <2bc5f8210803102102p31da06b5jfa7807bb727907a7@mail.gmail.com> <87myonlqys.fsf@ossau.uklinux.net> <2bc5f8210803260855m2f1a8295v5b9becfa615c7a8d@mail.gmail.com> <877iffssdn.fsf@ossau.uklinux.net> <2bc5f8210804031207s25be680aj99b50eaa1d66b6d7@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 1207776676 18165 80.91.229.12 (9 Apr 2008 21:31:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Apr 2008 21:31:16 +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 Apr 09 23:31:48 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 1JjhtM-0007lS-TH for guile-devel@m.gmane.org; Wed, 09 Apr 2008 23:31:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jjhsj-0004Q8-CB for guile-devel@m.gmane.org; Wed, 09 Apr 2008 17:31:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jjhrm-0003pM-43 for guile-devel@gnu.org; Wed, 09 Apr 2008 17:30:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jjhrh-0003kP-JN for guile-devel@gnu.org; Wed, 09 Apr 2008 17:30:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jjhrh-0003kC-BH for guile-devel@gnu.org; Wed, 09 Apr 2008 17:29:57 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JjhrT-0006El-DQ; Wed, 09 Apr 2008 17:29:43 -0400 Original-Received: from arudy (host86-145-183-175.range86-145.btcentralplus.com [86.145.183.175]) by mail3.uklinux.net (Postfix) with ESMTP id 2375A1F6C30; Wed, 9 Apr 2008 22:29:39 +0100 (BST) Original-Received: from laruns (laruns [192.168.0.10]) by arudy (Postfix) with ESMTP id 8F8BB3800D; Wed, 9 Apr 2008 22:29:38 +0100 (BST) In-Reply-To: <2bc5f8210804031207s25be680aj99b50eaa1d66b6d7@mail.gmail.com> (Julian Graham's message of "Thu, 3 Apr 2008 15:07:16 -0400") 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:7129 Archived-At: "Julian Graham" writes: > Were we to go this route (i.e., non-coexistence), I think the best > solution would be something along the lines of the divide between > Guile's built-in hash tables and SRFI-69 hash tables -- that is, > obvious incompatibility based on data type. But that seems like an > awful lot of work and a potential loss in terms of flexibility for > developers. I agree; so overall, it seems clear that we don't want to take this route. > With regard to supporting locked/not-owned: > > >> 1. Calling lock-mutex with a thread parameter different from the >> calling thread, and which isn't #f. I believe this should be a core >> feature (as well as a SRFI-18 one), and it had completely escaped my >> notice that this detail had evaporated from your patches. I believe >> you implemented this originally, then removed it following my attempt >> to draw a line between core stuff and SRFI-18 stuff - so I guess you >> thought that was one of the implications of what I wrote; sorry about >> that. Would it be easy at this point to reinstate this? > > That was my assumption, yes. Sorry! I can certainly reinstate, and > will do so in the next patch I submit. While we're discussing this, > though, any design issues you'd like to consider? E.g., this might > not be something we'd want every mutex to support, so we could add a > flag to make-mutex, a la the earlier stuff for external unlocking. I think it depends whether we see the existing make-mutex flags as a policing thing or as a trying-to-be-helpful-at-runtime thing. My view is that they are mostly trying to be helpful, specifically to catch the bugs where a developer who is expecting traditional mutex behaviour accidentally calls unlock-mutex from the wrong thread, or on a mutex that isn't locked. In addition, there is the possibility that some existing code might be relying on exceptions being raised in these cases. The (lock-mutex ... thread) case feels to me to be quite different from this, because the (lock-mutex ...) call that a developer has to write, in order to take advantage of the SRFI-18 features, is different at the source code level: to get the SRFI-18 behaviour, the developer has to explicitly supply the optional thread parameter. This makes it impossible (or as near impossible as we care about) that a developer would get the SRFI-18 behaviour by mistake; and existing code (which cannot specify the thread parameter, because it isn't supported yet!) will automatically continue to get the traditional behaviour. Therefore I don't see the same kind of need for a make-mutex flag here, as there was for the unlock cases. >> 2. Calling lock-mutex with thread parameter #f, such as to produce the >> SRFI-18 locked/not-owned state. My previous pure Scheme suggestion >> for locked/not-owned was based on my statement that: > > ... > >> In terms of the C/Scheme boundary, one possible representation of this >> would be to introduce a mutex-locked? primitive, which is significant >> when mutex-owner returns #f, and distinguishes between the normal >> unlocked state and locked/not-owned. > > ... > >> What do you think? > > I think that's quite elegant, actually. On initial consideration I > was going to suggest that we bring back the use of SCM_UNSPECIFIED in > the context of mutex ownership (that is, fat_mutex.owner can be > SCM_UNSPECIFIED, #f, or a thread) that I'd removed in the final > version of my patch -- after all, mutex-owner is for all intents and > purposes new to the API, so we've got some freedom in how it's > defined. ...But I think I prefer the solution you describe above, > since it has the additional benefit of exposing only as much > information about mutex state as a caller is interested in. So I'll > go with that, I think, and send you a new patch for the core that > incorporates all of this. Let me know if that's not okay. Sounds good to me! Regards, Neil