Commit | Line | Data |
---|---|---|
9af90aaf CR |
1 | Fibers 1.0.0 has a bug in run-fibers in which peer schedulers aren't destroyed - |
2 | so if you had 4 cores, 1 would be destroyed when run-fibers returned, but the | |
3 | other 3 would stay around. Each scheduler uses 3 file descriptors, so for | |
4 | machines with many cores, this resource leak adds up quickly - quickly enough | |
5 | that the test suite can even fail because of it. | |
6 | ||
7 | See https://github.com/wingo/fibers/issues/36. | |
8 | ||
9 | This fixes that. It should be safe to destroy the peer schedulers at the given | |
10 | point because the threads that could be running them are all either dead or the | |
11 | current thread. | |
12 | ||
13 | As of May 21, 2020, this bug still existed in the 1.0.0 (latest) release and in | |
14 | git master. | |
15 | --- a/fibers.scm 2020-05-21 18:38:06.890690154 -0500 | |
16 | +++ b/fibers.scm 2020-05-21 18:38:56.395686693 -0500 | |
17 | @@ -137,5 +137,6 @@ | |
18 | (%run-fibers scheduler hz finished? affinity)) | |
19 | (lambda () | |
20 | (stop-auxiliary-threads scheduler))))) | |
21 | + (for-each destroy-scheduler (scheduler-remote-peers scheduler)) | |
22 | (destroy-scheduler scheduler) | |
23 | (apply values (atomic-box-ref ret)))))) | |
24 |