IRC channel logs
2024-02-12.log
back to list of logs
<rlb>civodul: no idea, but I can look at both options -- offhand, I have a feeling that moving the signal thread to pure C might be preferable to moving things to scm for now because *if* we need condition vars and mutexes, they're appear to be more complex, and complex might not be what we want during fork and/or thread teardown... <rlb>dthompson: no idea - no experience with fibers at all yet. <rlb>civodul: I'll plan to look at the options a bit. <rlb>civodul: I did think that having the core of join-thread in C for now might make it more "solid", and/or easier to tell it's correct by inspection (or incorrect), but as mentioned, I also wonder if there might be a simpler formulation overall if/when we have time to figure it out and/or are up for a broader overhaul. <rlb>Fundamentally, though, I think on_thread_exit either has to do less, or we have to wait on it. <rlb>(more complex on the scm side -- and note that we can't do much iirc during thread startup, before we let things loose, i.e. no scheme code run during guilify_1?). <rlb>dthompson: hmm, any particular kind of trouble? I suppose one notable different now is that it's using a pthread cv and mutex directly, rather than the scheme-side versions, so it's not guaranteed to be fair, and if the scheme flavors were doing something extra (say running some other code on that thread while waiting?), then that won't happen anymore... <rlb>sneek: later tell civodul -- either way, updated the branch with the smob cleanup and a bug fix. I also wondered what's actually allowed in on_thread_exit, since I think we're outside with_guile at that point... <cow_2001>i am thoroughly confused by the hall dependencies field <cow_2001>(dependencies ("guile-irc")) results with weird messages <rlb>civodul: so my current (maybe wrong), guess is that without some broader restructuring, if we need to wait on on_thread_exit in thread-join in general, then we might want to favor C for now, since that function runs in (presumably) an unusual envt, i.e. no with_guile, etc. And if the signal thread wants to be able to run arbitrary scheme code (right now it does async-related things?), maybe it has to be a scheme thread. <rlb>civodul: well, it's not %thread-join that runs without guile, it's the on_thread_exit side (if I'm right about its context). So if there's a safe way for on_thread_exit to unblock a scheme thread, then might not be hard to move all of thread-join back to scheme. <rlb>i.e. if we can safely call the scheme mutex/cv functions from the end of on_thread_exit (both now, and in the future). <apteryx>cow_2001: hi! (gnu packages) is provided by guix; do you have it installed? <apteryx>I see! On my Guix System, the module is put on my GUILE_LOAD_PATH via /run/current-system/profile/share/guile/site/3.0, but that's because I have the guix-daemon service running. <apteryx>I'll ponder about a proper resolution, but in the meantime you could hack your way by working within a 'guix shell guix' environment <cow_2001>GUILE_LOAD_PATH's /home/yuval/.guix-profile/share/guile/site/3.0 right now <apteryx>by pulling guix in the environment it'll find the guix modules <cow_2001>i'm trying it now in a `guix shell -C --pure guile-hall guile coreutils bash which vim guix` <cow_2001>(if indeed it is a bug and not me being silly)