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

[Mark H Weaver <mhw@netris.org>]

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