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!
>From 692d4442be6d811dadae98083c45f4898860c718 Mon Sep 17 00:00:00 2001
From: Nala Ginrut <nalagin...@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 <chaoseter...@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
