From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18 Date: Sat, 08 Jun 2013 17:44:29 +0800 Organization: HFG Message-ID: <1370684669.2610.122.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-ECF4ApDa8OFdIzGETktr" X-Trace: ger.gmane.org 1370684679 1385 80.91.229.3 (8 Jun 2013 09:44:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Jun 2013 09:44:39 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Jun 08 11:44:39 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UlFhP-00040D-BW for guile-devel@m.gmane.org; Sat, 08 Jun 2013 11:44:39 +0200 Original-Received: from localhost ([::1]:60759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlFhP-0004oj-0T for guile-devel@m.gmane.org; Sat, 08 Jun 2013 05:44:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlFhL-0004oe-DX for guile-devel@gnu.org; Sat, 08 Jun 2013 05:44:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UlFhK-0000uV-Ey for guile-devel@gnu.org; Sat, 08 Jun 2013 05:44:35 -0400 Original-Received: from mail-pd0-f174.google.com ([209.85.192.174]:37431) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UlFhK-0000uP-7C for guile-devel@gnu.org; Sat, 08 Jun 2013 05:44:34 -0400 Original-Received: by mail-pd0-f174.google.com with SMTP id 10so4758551pdc.19 for ; Sat, 08 Jun 2013 02:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:organization:content-type :x-mailer:mime-version; bh=r4aP/rcumr0cFU+LP9QmZVCWLzV/cX7EQmbROsg7xxk=; b=wi7j+Dn4/1u3pMeRMzmqb6inA4EE5bi/s08wSf7lrEaA0d/YNw3CT/iPXubIYimxBL ptfxSvuDh0ERTt7QV6Rq6DHCJktG7xw1yKol8yXPybAzp9iSQDH5aFv4CVe1S1HB5uds C/+wLOr3arrWwo66dllfXF6xcsQo/SQgimqIDoX3kMgv1mb2o7TA5Y4Bt89bZwJzUijK hWHOZgDjKv9cDU/lm61XbOH3mu32U4GFrEcqlsbjCI+3dCaCZO4K43fDmjxamYTyubmi GHqfkPmdBLipHKU3zR8HGbeGRaTiXcbrWATNKCmiXlL1r93NoojX9IpGTqMN4NJyPBx9 e+Vw== X-Received: by 10.68.213.162 with SMTP id nt2mr2186744pbc.179.1370684672972; Sat, 08 Jun 2013 02:44:32 -0700 (PDT) Original-Received: from [147.2.147.112] ([61.14.130.226]) by mx.google.com with ESMTPSA id qe10sm95176pbb.2.2013.06.08.02.44.31 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Sat, 08 Jun 2013 02:44:32 -0700 (PDT) X-Mailer: Evolution 3.4.4 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.192.174 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16472 Archived-At: --=-ECF4ApDa8OFdIzGETktr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit According to srfi-18: ---------------------cut---------------------- Time objects and timeouts ...... a time object represents an absolute point in time an exact or inexact real number represents a relative time in seconds from the moment the primitive was called #f means that there is no timeout ---------------------end---------------------- Attached the patch to fix such a situation: ========== scheme@(guile-user)> (mutex-unlock! m condv #f) ERROR: In procedure unlock-mutex: ERROR: Wrong type (expecting real number): #f ========== And I do know that `mutex-unlock!' uses timeout as the last optional argument, usually users won't pass timeout when they don't need it. But I do think it's necessary to stick to the standard as possible as we can. Thanks! --=-ECF4ApDa8OFdIzGETktr Content-Disposition: attachment; filename*0=0001-mutex-unlock-should-allowed-f-as-timeout-according-t.pat; filename*1=ch Content-Type: text/x-patch; name="0001-mutex-unlock-should-allowed-f-as-timeout-according-t.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit >From 692d4442be6d811dadae98083c45f4898860c718 Mon Sep 17 00:00:00 2001 From: Nala Ginrut Date: Sat, 8 Jun 2013 17:27:14 +0800 Subject: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18 Report `mutex-unlock!' doesn't accept #f as timeout. Reported by Chaos Eternal * libguile/threads.c (scm_unlock_mutex_timed): mutex-unlock! should allowed #f as timeout according to srfi-18. #f means that there is no timeout. Though `mutex-unlock!' won't use optional 'timeout' when it's #f usually, stick to SRFI standard as possible is prefered. --- libguile/threads.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libguile/threads.c b/libguile/threads.c index 04897e3..3e9911d 100644 --- a/libguile/threads.c +++ b/libguile/threads.c @@ -1692,7 +1692,7 @@ SCM_DEFINE (scm_unlock_mutex_timed, "unlock-mutex", 1, 2, 0, scm_t_timespec cwaittime, *waittime = NULL; SCM_VALIDATE_MUTEX (1, mx); - if (! (SCM_UNBNDP (cond))) + if (! (SCM_UNBNDP (cond)) && ! scm_is_false (timeout)) { SCM_VALIDATE_CONDVAR (2, cond); -- 1.7.10.4 --=-ECF4ApDa8OFdIzGETktr--