From 4f2b624830d9df0e96d8b78a76e212d1166755c3 Mon Sep 17 00:00:00 2001 From: Matthew Mondor Date: Tue, 8 Sep 2015 18:24:39 -0400 Subject: [PATCH] Update README with latest test information --- ecl-gc-bug/README | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/ecl-gc-bug/README b/ecl-gc-bug/README index 0ef5457..f340134 100644 --- a/ecl-gc-bug/README +++ b/ecl-gc-bug/README @@ -18,6 +18,14 @@ locked waiting on a mutex. Occasionally, instead of busy-looping, we get an idle hang. When avoiding to use stdio, this is a generally avoidable bug; I have daemons using ECL with decent uptimes. +When disabling the GC_NETBSD_THREADS_WORKAROUND quirk in libgc, it +seems to require less time for (test4) to freeze. This workaround +ensures synchronization when resuming threads. + +When first doing some operations growing the heap, it takes more +time for (test4) to reproduce the bug, because there is a relation +between the bug and multithreaded heap growth. + - Verify again that the proper signals are sent for the proper reasons and they they are matched by the proper signal responses. - Investigate if the signal masks are sometimes bogus, or if the @@ -29,3 +37,5 @@ avoidable bug; I have daemons using ECL with decent uptimes. situations happen in restartable or non-restartable calls. - NetBSD has pthread_suspend_np(3) and pthread_resume_np(3). Verify if Boehm-GC can use those, and if so, enable them and test. + These appear to currently only be used for OpenBSD user threads, + and also require OpenBSD-specific pthread_stackseg_np(). -- 2.9.0