* [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18
@ 2013-06-08 9:44 Nala Ginrut
2013-06-10 18:53 ` Mark H Weaver
0 siblings, 1 reply; 3+ messages in thread
From: Nala Ginrut @ 2013-06-08 9:44 UTC (permalink / raw)
To: guile-devel
[-- 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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18
2013-06-08 9:44 [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18 Nala Ginrut
@ 2013-06-10 18:53 ` Mark H Weaver
2013-06-13 4:46 ` Nala Ginrut
0 siblings, 1 reply; 3+ messages in thread
From: Mark H Weaver @ 2013-06-10 18:53 UTC (permalink / raw)
To: Nala Ginrut; +Cc: guile-devel
Hi,
Nala Ginrut <nalaginrut@gmail.com> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18
2013-06-10 18:53 ` Mark H Weaver
@ 2013-06-13 4:46 ` Nala Ginrut
0 siblings, 0 replies; 3+ messages in thread
From: Nala Ginrut @ 2013-06-13 4:46 UTC (permalink / raw)
To: Mark H Weaver; +Cc: guile-devel
On Mon, 2013-06-10 at 14:53 -0400, Mark H Weaver wrote:
> 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.
>
Sorry for the quick&dirty patch, but thanks for pointed it out ;-P
> Thanks,
> Mark
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-06-13 4:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-08 9:44 [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18 Nala Ginrut
2013-06-10 18:53 ` Mark H Weaver
2013-06-13 4:46 ` Nala Ginrut
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).