aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--gnu/local.mk1
-rw-r--r--gnu/packages/guile-xyz.scm5
-rw-r--r--gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch24
3 files changed, 29 insertions, 1 deletions
diff --git a/gnu/local.mk b/gnu/local.mk
index 1d9de9a57e..2f24f892b1 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1053,6 +1053,7 @@ dist_patch_DATA = \
%D%/packages/patches/guile-3.0-relocatable.patch \
%D%/packages/patches/guile-linux-syscalls.patch \
%D%/packages/patches/guile-3.0-linux-syscalls.patch \
+ %D%/packages/patches/guile-fibers-destroy-peer-schedulers.patch \
%D%/packages/patches/guile-gdbm-ffi-support-gdbm-1.14.patch \
%D%/packages/patches/guile-present-coding.patch \
%D%/packages/patches/guile-rsvg-pkgconfig.patch \
diff --git a/gnu/packages/guile-xyz.scm b/gnu/packages/guile-xyz.scm
index 674b1f922b..a1deee32d1 100644
--- a/gnu/packages/guile-xyz.scm
+++ b/gnu/packages/guile-xyz.scm
@@ -523,7 +523,10 @@ Unix-style DSV format and RFC 4180 format.")
(("#:use-module \\(fibers\\)")
(string-append "#:use-module (fibers)\n"
"#:use-module (ice-9 threads)\n")))
- #t))))
+ #t))
+ (patches
+ ;; fixes a resource leak that causes crashes in the tests
+ (search-patches "guile-fibers-destroy-peer-schedulers.patch"))))
(build-system gnu-build-system)
(arguments
'(;; The code uses 'scm_t_uint64' et al., which are deprecated in 3.0.
diff --git a/gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch b/gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch
new file mode 100644
index 0000000000..8bb7153153
--- /dev/null
+++ b/gnu/packages/patches/guile-fibers-destroy-peer-schedulers.patch
@@ -0,0 +1,24 @@
+Fibers 1.0.0 has a bug in run-fibers in which peer schedulers aren't destroyed -
+so if you had 4 cores, 1 would be destroyed when run-fibers returned, but the
+other 3 would stay around. Each scheduler uses 3 file descriptors, so for
+machines with many cores, this resource leak adds up quickly - quickly enough
+that the test suite can even fail because of it.
+
+See https://github.com/wingo/fibers/issues/36.
+
+This fixes that. It should be safe to destroy the peer schedulers at the given
+point because the threads that could be running them are all either dead or the
+current thread.
+
+As of May 21, 2020, this bug still existed in the 1.0.0 (latest) release and in
+git master.
+--- a/fibers.scm 2020-05-21 18:38:06.890690154 -0500
++++ b/fibers.scm 2020-05-21 18:38:56.395686693 -0500
+@@ -137,5 +137,6 @@
+ (%run-fibers scheduler hz finished? affinity))
+ (lambda ()
+ (stop-auxiliary-threads scheduler)))))
++ (for-each destroy-scheduler (scheduler-remote-peers scheduler))
+ (destroy-scheduler scheduler)
+ (apply values (atomic-box-ref ret))))))
+