* bug#29704: Guile 2.2.2: SRFI-18, condition variables, timeouts
@ 2017-12-14 1:37 David Beswick
2018-02-16 14:31 ` Ludovic Courtès
0 siblings, 1 reply; 2+ messages in thread
From: David Beswick @ 2017-12-14 1:37 UTC (permalink / raw)
To: 29704
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* bug#29704: Guile 2.2.2: SRFI-18, condition variables, timeouts
2017-12-14 1:37 bug#29704: Guile 2.2.2: SRFI-18, condition variables, timeouts David Beswick
@ 2018-02-16 14:31 ` Ludovic Courtès
0 siblings, 0 replies; 2+ messages in thread
From: Ludovic Courtès @ 2018-02-16 14:31 UTC (permalink / raw)
To: David Beswick; +Cc: 29704-done
Hi David,
David Beswick <dlbeswick@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’.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-02-16 14:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-14 1:37 bug#29704: Guile 2.2.2: SRFI-18, condition variables, timeouts David Beswick
2018-02-16 14:31 ` Ludovic Courtès
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).