[gnunet-scheme] branch master updated (cc6d130 -> ff36dc8)

[gnunet]

This is an automated email from the git hooks/post-receive script.

maxime-devos pushed a change to branch master
in repository gnunet-scheme.

    from cc6d130  tests/util: Fix non-deterministic hang in 
'garbage-collectable'.
     new eb98ea0  tests/mq: Notice "nothing lost when sending concurrently" 
non-deterministically hangs.
     new 4b0838f  tests/mq: Add more information on "nothing lost when sending 
concurrently".
     new 80eb208  tests/mq: Skip "nothing lost when sending concurrently".
     new ff36dc8  tests/lost-and-found: Note that "concurrent losing" is a bit 
slow.

The 4 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 tests/lost-and-found.scm |  5 ++++-
 tests/mq.scm             | 10 ++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/tests/lost-and-found.scm b/tests/lost-and-found.scm
index 5ff08b2..908f72b 100644
--- a/tests/lost-and-found.scm
+++ b/tests/lost-and-found.scm
@@ -177,7 +177,10 @@ bypassed by calling @code{add-found!} directly)."
   (perform-operation (collect-lost-and-found-operation lost-and-found)))
 
 ;; In the current implementation of Guile, while to a degree GC is 
parellelised,
-;; gc hooks are serialised (or maybe not, since ‘this hook is run  
+;; gc hooks are serialised (or maybe not, since ‘this hook is run
+;;
+;; This is a slow test -- it tends to take between 3 s and 15 s to run
+;; on some rando's computer (with recent CPU model).
 (test-assert "concurrent losing"
   (run-fibers
    (lambda ()
diff --git a/tests/mq.scm b/tests/mq.scm
index 8d456ac..9d1e946 100644
--- a/tests/mq.scm
+++ b/tests/mq.scm
@@ -467,6 +467,16 @@ with @code{x}."
   missing)
 
 ;; But possibly out-of-order!
+;; TODO: infrequently hangs, in the last attempt it hung
+;; after being run 14 times in a row.
+;;
+;; Does not happen with #:hz 0 (i.e., without preemption).
+;; IIRC, does not happen with #:parallelism 1 (i.e., a single OS-level
+;; thread).  After debugging, it turns out that the (thread ...)
+;; sometimes hangs, even though it never performs operations
+;; (TODO: confirm by replacing 'perform-operation') and CPU usage
+;; is 0%?
+(test-skip 1) ; too much of a time sink to investigate
 (test-equal "nothing lost when sending concurrently"
   '()
   (let* ((mq (make-message-queue no-handlers

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.