From: Nala Ginrut <nalaginrut@gmail.com>
To: guile-devel@gnu.org
Subject: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18
Date: Sat, 08 Jun 2013 17:44:29 +0800 [thread overview]
Message-ID: <1370684669.2610.122.camel@Renee-desktop.suse> (raw)
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
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!
[-- Attachment #2: 0001-mutex-unlock-should-allowed-f-as-timeout-according-t.patch --]
[-- Type: text/x-patch, Size: 1142 bytes --]
From 692d4442be6d811dadae98083c45f4898860c718 Mon Sep 17 00:00:00 2001
From: Nala Ginrut <nalaginrut@gmail.com>
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 <chaoseternal@shlug.org>
* 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
next reply other threads:[~2013-06-08 9:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-08 9:44 Nala Ginrut [this message]
2013-06-10 18:53 ` [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18 Mark H Weaver
2013-06-13 4:46 ` Nala Ginrut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1370684669.2610.122.camel@Renee-desktop.suse \
--to=nalaginrut@gmail.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).