GNU bug report logs - #29704
Guile 2.2.2: SRFI-18, condition variables, timeouts

Previous Next

Package: guile;

Reported by: David Beswick <dlbeswick <at> gmail.com>

Date: Thu, 14 Dec 2017 02:33:01 UTC

Severity: normal

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29704 in the body.
You can then email your comments to 29704 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guile <at> gnu.org:
bug#29704; Package guile. (Thu, 14 Dec 2017 02:33:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Beswick <dlbeswick <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-guile <at> gnu.org. (Thu, 14 Dec 2017 02:33:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Beswick <dlbeswick <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: Guile 2.2.2: SRFI-18, condition variables, timeouts
Date: Thu, 14 Dec 2017 12:37:41 +1100
Hello, I'm using Guile 2.2.2 built from source as downloaded from the 
project
website.

$ guile -v
guile (GNU Guile) 2.2.2


I would expect the following command to return in 5 seconds:
$ guile -c '(use-modules (srfi srfi-18)) (let ((cv 
(make-condition-variable)) (m (make-mutex))) (mutex-lock! m) 
(mutex-unlock! m cv 5))'

However, it returns instantly for me. This command works as expected:
$ guile -c "(use-modules ((srfi srfi-18) #:prefix srfi:)) (let ((cv 
(srfi:make-condition-variable)) (m (srfi:make-mutex))) (srfi:mutex-lock! 
m) (srfi:mutex-unlock! m cv (+ (current-time) 5)))"


It's stated on the page https://srfi.schemers.org/srfi-18/srfi-18.html that:

"All synchronization primitives which take a timeout parameter accept three
types of values as a timeout, with the following meaning:

* 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"

Assuming this page is accurate, then the case in the test code
falls under the second dot point from the spec.

The source in module/srfi/srfi-18.scm seems to pass the timeout parameter
unaltered to Guile's wait-condition-variable function, and that parameter is
said in the docs to be "either a integer as returned by ‘current-time’ 
or a pair
as returned by ‘gettimeofday’". I think that would cause the unexpected
behaviour that I see.

I have some time at the moment where I could address this, please let me 
know if
you would like me to work on a fix.

Regards,
David




Reply sent to ludo <at> gnu.org (Ludovic Courtès):
You have taken responsibility. (Fri, 16 Feb 2018 14:32:02 GMT) Full text and rfc822 format available.

Notification sent to David Beswick <dlbeswick <at> gmail.com>:
bug acknowledged by developer. (Fri, 16 Feb 2018 14:32:02 GMT) Full text and rfc822 format available.

Message #10 received at 29704-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: David Beswick <dlbeswick <at> gmail.com>
Cc: 29704-done <at> debbugs.gnu.org
Subject: Re: bug#29704: Guile 2.2.2: SRFI-18, condition variables, timeouts
Date: Fri, 16 Feb 2018 15:31:02 +0100
Hi David,

David Beswick <dlbeswick <at> gmail.com> skribis:

> I would expect the following command to return in 5 seconds:
> $ guile -c '(use-modules (srfi srfi-18)) (let ((cv
> (make-condition-variable)) (m (make-mutex))) (mutex-lock! m)
> (mutex-unlock! m cv 5))'
>
> However, it returns instantly for me. This command works as expected:
> $ guile -c "(use-modules ((srfi srfi-18) #:prefix srfi:)) (let ((cv
> (srfi:make-condition-variable)) (m (srfi:make-mutex)))
> (srfi:mutex-lock! m) (srfi:mutex-unlock! m cv (+ (current-time) 5)))"
>
>
> It's stated on the page https://srfi.schemers.org/srfi-18/srfi-18.html that:
>
> "All synchronization primitives which take a timeout parameter accept three
> types of values as a timeout, with the following meaning:
>
> * 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"
>
> Assuming this page is accurate, then the case in the test code
> falls under the second dot point from the spec.

Sorry the late reply.  I believe this and a similar issue with
‘thread-sleep!’ is now fixed:

  https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=2c7b350f93564daee16a311c001a85577d4b69e1
  https://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.2&id=39860539599f74958c0cc9008fc6fa271349b58b

Let me know if anything’s wrong!

Thank you,
Ludo’.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 17 Mar 2018 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 12 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.