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.
<sneek>Got it.
<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>i got that impression
<civodul>that’s a bug, to me
<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>civodul: ^
<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" :)
<rlb>s/you'll/you can/
<alextee>can you not have # characters inside a string ("#") ?
<alextee>nvm
<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)
<apteryx>it's from (system repl debug)
<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.
<teddd>rekado: I see, thanks
<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.
<mwette>(ice-9 futures) maybe?
<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)
<apteryx>not of bindings it contains
<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.