IRC channel logs
2025-09-13.log
back to list of logs
<rlb>dsmith: pushed a couple of patches to fix the problems we found. <dsmith>Had fun time debugging last few days. A nice change <old>ArneBab: I remember you asking if I found a way to speed up fibers you would be interested <old>Well I've made some modification to the scheduler in my vendored version and got very good gain <ArneBab>old: does your "single threaded" remark mean that this would not work for a multi-threaded usecase? <identity>it does seem that way, without the atomics <ArneBab>identity: I’m not sure whether there are non-blocking options like separating by thread and only making work-stealing atomic. <ArneBab>old: do I understand your hint corectly that the stack-push-list! with reverse is the most expensive operation? And that using a deque instead of a stack could fix it? <resica>Hey, dthompson, me again. Listen, I got a major confusion how to launch chickadee. Do I use guile3.0 directly or the chickadee play script? <resica>And no matter what, it says unbound variable for draw-text and vec2 with your first example. <dsmith>There is a problem (segfault) with ac_cv_func_posix_spawn_file_actions_addclosefrom_np on FreeBSD. <dsmith>So. How to modify configure.ac so that it selects the correct ac_cv_func_posix_spawn_file_actions_addclosefrom_np ? <dsmith>s/ac_cv_func_posix_spawn_file_actions_addclosefrom_np/posix_spawn_file_actions_addclosefrom_np/ <old>ArneBab: yes you would need to impement something that is multi-thread safe. could be a simple mutex to start with. but the best thing would be to have a doubly-linked list like the Linux kernel has <old>you keep the atomicity with nodes, but you don't reallocate thing all the time. The node is embedded within the task itself <rlb>dsmith: offhand guess - we're missing a header? <rlb>(Hmm, though looks like linux needs that too.) <old>ArneBab: anyway, I manage to drop my memory usage of fibers by optimizing certain tasks in my case. So I will keep using the vanilla scheduler. But I think there are possibility to reduce memory usage in certain workload <ArneBab>old: do you mean your pure scheme fibers scheduler or the one in the guile-fibers project? (I shouldn’t ask two questions … sorry) <rlb>dsmith: does look like that name is unavailable without "#include <spawn.h>", i.e. needed it in a trivial test program for that binding to be defined. <ArneBab>old: I had an actual memory leak with my fibers usage for quite a while because I missed to stop them when the socket closed. Since fixing that, https://dryads-wake.1w6.org/sun actually manages to stay online and serve 30-60 clients with the weakest virtual server I could rent. <dsmith>rlb, I've been looking into it a little deeper. IIUC, the build becomes a mixture of fbsd and and glib lib/spawn* <dsmith>So the question is, how do we get configure to specify the system library spawn* stuff insted of glib <rlb>OK, so it's not just that we're leaving off spawn.h during the probe for that symbol and so falling back (inconsistently) to compat for that symbol but system for spawn (say if we can find the system spawn without spawn.h, but not that one)? <rlb>(Was just a vague guess -- not saying I think that's what's happening.) <rlb>(Only thing I did was test a foo.c without spawn.h and saw that addclose was undefined.) <rlb>(I suppose you might be able to test that, if you don't already know by adding spawn.h to the AC_CHECK_HEADERS?) <old>ArneBab: My variant in pure scheme only implement the event.scm module with epoll in Guile. Otherwise, nothing different from vanilla fibers <old>but the possibility to reduce memory usage is from the vanilla scheduler <old>where runqueues are implemented as two stacks (lists) and are swapped <old>this simple action of swapping require reversing the stack to keep the FIFO semantic of a runqueue. This involve allocation of cons-cells <old>so I suspect that with a very high number of tasks, the GC will become the bottleneck at some point