IRC channel logs

<old>ehh that POSIX timer API is so not well thought

<old>the only thing I would need for it is for the kernel to set a flag at a location on timer expiration

<old>but now someone thought that spawning a new thread was better

<old>s/now/no

<lechner>"but no someone..." ?

<old>but no,

<old>as in, nobody thought of doing better than spawning a god damn thread every time the timer got expired

<old>timerfd_create is actually better but not portable sadly

<dsmith>old, I was going to mention timerfd, but didn'

<dsmith>t

<dsmith>because linux only

<dsmith>Or do *bsd's have it?

<lechner> https://man.freebsd.org/cgi/man.cgi?query=timerfd_create&sektion=2

<dsmith>Does fibers used epoll? Does it use kqueue on *bsd?

<dsmith>lechner, cool

<old>sure freebsd has it but not MacOS or windows

<old>anyway, we want to get rid of the signal delivery thread so perhaps it's better to avoid this at all

<old>I do have this WIP patch for removing it and I think it would work nicely with timer as well

<old>also I read from a blog post that the portable library like libeven basically use poll with a timeout to implement timer

<old>that and a heap data-structure, basically a timer wheel lol

<dsmith><cough>signalfd</cough>

<dsmith>;^}

<old>thinking more about it and

<old>we have two manager threads. signal delivery and finalizers

<old>I think we might want a event thread instead that manage everything

<old>sounds like re-inventing the wheel here, but I think it could be quite powerful for Guile

<old>it could handle signals, emulate timers and handle finalizers

<old>probably more events could be added in the future as well if we have use cases

<rlb>seems plausible, as long as we can "select" on all the relevant events --- can always dispatch to "worker threads/pools" from there if some kind of event ever calls for it.

<old>yes indeed

<old>I would implement it with ppoll

<old>wonder what civodul think about this

<old>tho I know he wants to get rid of the signal thread

<rlb>I guess the main difference might be per-kind "rates" if they were ever high enough to matter (and they didn't otherwise compete"?

<rlb>s/"\?/")?/ :)

<rlb>i.e. if a finalizer thread is only doing signals (setting indicators), it *might* not have to worry about contention wrt responding to signals.

<rlb>s/finalizer thread/signal thread/

<rlb>What I meant to say was "if a signal thread is only doing signals (setting indicators), it *might* not have to worry about contention wrt finalizations".

<old>right

<old>that might be a problem

<old>if finalizer are slow to run it can slow down responsiveness

<old>of signals

<old>while rn a slow finalizer only add latency to other finalizers

<rlb>That's the kind of thing I'd guess you might well need a thread or thread-pool for, and then maybe we're back where we started...

<rlb>(roughly)

<rlb>Though having a thread pool for finalizers would allow "scaling" if we needed it.

<rlb>maybe?

<old>that makes sens

<rlb>(but that's true now too)

<rlb>(if it's true at all)

<rlb>Hmm, hadn't thought about whether we have any kind of "backpressure" on finalizers. i.e. do we eventually push back on the submission of work there, or can the pile keep growing until it kills the process if the thread can't keep up (in theory)?

<old>the GC notify about finalizer by writting to a pipe

<old>the finalizee thread read from that pipe

<old>if the finalizer thread can not keep up, then the GC will eventually freeze

<old>that can lead to deadlock in theory

<old>because the GC will wait on write to the buf

<old>and the finalizer might be allocating from the GC

<rlb>oh, fun :)

<old>thing is, the GC batches finalizer notification, I think

<old>so in pratice it should be ok

IRC channel logs

2026-09-29.log