IRC channel logs
2024-04-05.log
back to list of logs
<rlb>wingo: suspect it'd be good to get some fix for that into the next release ^ old has generously provided a slightly different arrangement, and I'd be happy to jump in whichever direction you think more appropriate (between that and https://codeberg.org/rlb/guile/src/branch/rev-parallel-tests ) Also could imagine we might want to switch to a more broadly different approach in the end. I was just working with what we had. <rlb>Both are on top of the parallel testing changes, because those trivially expose the issue. <rlb>(But I suspect we may well have other workloads hitting it in the wild.) <rlb>civodul: possibly a ping for you too -- I finally pushed old's changes to my fixes for the fork hang problem as https://codeberg.org/rlb/guile/src/branch/rev-parallel-tests-dion, and rev-parallel-tests there is still my current proposal (which has changed a bit, handling exited via new atomics-internal.h functions). Happy to pursue this whatever way y'all prefer once you have an impression. <rlb>(Oh, and the thread fixes are only the last handful of commits on each branch -- the rest just make it easy to provoke the issue (say via make -j5 check).) <old>rlb: Usage of atomic can be dropped if access to thread a result is done only through the result mutex, which I suspect is not a contentation point. This would certainly make the code more maintanable <rlb>If I understand you, that's fine too if we'd rather -- I'd just originally thought the fast-path might be nice. Although that was before I realized I might need to add the additional scm atomic calls to allow it. <rlb>(Suppose it also could depend on whether people might want those additional atomics anyway -- dunno.) <old>right. the atomic is really for the fast-path, but I doubt that this is meaningful tbh <old>but I believe the code to be correct, so I leave this to be decided by others :-) <rlb>Agreed. The lower cost is nice, but may rarely matter.