From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18 Date: Mon, 10 Jun 2013 14:53:59 -0400 Message-ID: <87wqq1vltk.fsf@tines.lan> References: <1370684669.2610.122.camel@Renee-desktop.suse> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1370890488 15604 80.91.229.3 (10 Jun 2013 18:54:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Jun 2013 18:54:48 +0000 (UTC) Cc: guile-devel@gnu.org To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jun 10 20:54:45 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 1Um7El-000156-Jk for guile-devel@m.gmane.org; Mon, 10 Jun 2013 20:54:39 +0200 Original-Received: from localhost ([::1]:42515 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um7El-000200-8u for guile-devel@m.gmane.org; Mon, 10 Jun 2013 14:54:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um7Ea-0001pe-4C for guile-devel@gnu.org; Mon, 10 Jun 2013 14:54:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Um7EY-0005Md-R2 for guile-devel@gnu.org; Mon, 10 Jun 2013 14:54:28 -0400 Original-Received: from world.peace.net ([96.39.62.75]:55787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Um7EY-0005Kf-Nt for guile-devel@gnu.org; Mon, 10 Jun 2013 14:54:26 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Um7EH-0006Gv-65; Mon, 10 Jun 2013 14:54:09 -0400 In-Reply-To: <1370684669.2610.122.camel@Renee-desktop.suse> (Nala Ginrut's message of "Sat, 08 Jun 2013 17:44:29 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:16476 Archived-At: Hi, Nala Ginrut writes: > 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. Agreed, good catch! > 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); This isn't quite right. If 'timeout' is false, then you fail to validate 'cond'. Anyway, I pushed a similar patch to stable-2.0. Thanks, Mark