IRC channel logs
2024-02-09.log
back to list of logs
<rlb>sneek: later tell civodul think I got it, though not sure what we're going to want to do about it. I think the key problem is that threads keep running via on_thread_exit *after* scm_join_thread returns (quite surprised me). And primitive-fork depends on threads (e.g. the signal thread) being completely finished at that point. Instead, the signal thread vanishes across the fork while still holding the signal lock. <apteryx>neat, the name of the calling procedure can be introspected via the stack interface <apteryx>e.g. (frame-procedure-name (stack-ref (make-stack #t) 1)) <apteryx>got it working with (logging logger) from Guile-Lib: 2024-02-09 04:38:38 guix/packages.scm:1151:8: (transitive-inputs) DEBUG: hasn't seen item: #<package linux-libre-headers@5.15.49 gnu/packages/commencement.scm:2551 7f936eb5f0b0> <rlb>wingo civodul: very "cheap" fix for the fork bug - https://paste.debian.net/1306765/ I suppose there might also be broader questions about what join's supposed to mean, but that avoids threads surviving the fork. <rlb>(Of course with that, we'd also need to be sure we don't decrement the count too early in on_thread_exit, and I imagine it's not OK to wait forever.) <civodul>rlb: hey! that’s brittle and could run infinitely, for instance if the user code is purposefully calling ‘primitive-fork’ despite having several therads <sneek>civodul, you have 2 messages! <sneek>civodul, rlb says: one thing I just noticed that surprised me (not sure if it's relevant yet) is that threads keep running after they're joined, i.e. on_thread_exit may (always?) run afterward. <sneek>civodul, rlb says: think I got it, though not sure what we're going to want to do about it. I think the key problem is that threads keep running via on_thread_exit *after* scm_join_thread returns (quite surprised me). And primitive-fork depends on threads (e.g. the signal thread) being completely finished at that point. Instead, the signal thread vanishes across the fork while still holding the signal lock. <civodul>but yes, it seems like scm_join_thread might return before the underlying pthread really exited <civodul>other option would be to turn the signal thread into a raw pthread_t instead of a full-blown Scheme thread <civodul>i think i looked into it and concluded it was not possible, but i’m not sure why <rlb>Right - that was just a quick hack. For a real fix I was wondering about the possibility of having join-thread wait until on_thread_exit finishes. Then we'd just join the signal thread without a timeout, and other uses might be no worse off... <rlb>Suppose it's plausible to expect all-threads, for example, to reflect the thread you're joining, after the join. <rlb>Right now, you'll see "zombies" :) <alextee>can you not have # characters inside a string ("#") ? <rlb>civodul: in any case, I think either join (or at least fork) has to have a way to wait until on_thread_exit finishes, or on_thread_exit can't be doing anything that "matters", i.e. can't lock, etc. <rlb>I'd vaguely wondered if there's any chance we could eliminate on_thread_exit in favor of scheme-side/driven clean-up in %call-with-new-thread or something... <rlb>But that'd only be OK if, for example, we don't want to allow/support pthread_cancel? Noticed we don't use it ourselves anymore. <rlb>Hmm, I have an idea for a fix -- I'll it try later... <apteryx>useful snippet to print a stack trace with a configured width in a program: (print-frames (stack->vector (make-stack #t)) #:width 200) <teddd>Why does `with-output-to-file` work with `system*` but `with-output-to-string` doesn't ? <rekado>teddd: system* output capture/redirection requires a file port. The manual says something about this, but I haven’t been able to find it just now. <rlb>Do we already have something like clj's promise? There (promise) creates an object to which a value can be delivered via (deliver p value). Attempts to get the value via (deref p) before it is delivered block, and subsequent attempts just return the same value -- all safely wrt concurrency. <apteryx>can we retrieve the source-properties of a binding fetched via frame-lookup-binding ? <apteryx>I think the closest we can do without syntax-source is get the source properties of a frame (of a function call) <rlb>mwette: thanks, though that's not quite what I'd want, i.e. it entangles the delivery with the computation. With a the clj-style promise, any thread (or threads) can deliver the value (first one wins). <rlb>I have the clj promises for lokke, so if we ever want them... But just wanted to see if we might already provide something similar.