[PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18

[PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18

[Nala Ginrut]

[-- 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

Re: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18

[Mark H Weaver]

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

Re: [PATCH] mutex-unlock! should allowed #f as timeout according to srfi-18

[Nala Ginrut]

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