<wingo>sneek: later tell civodul i believe it is a bug. in a pre-unwind handler, you want to make it so that if it throws again, it is handled by the handler that was current when the with-exception-handler was invoked (the dynamically outer handler) <wingo>sneek: later tell civodul to implement this, when a throw first starts, we capture the current handler stack, and arrange for subsequent throws to resolve via that captured handler stack <wingo>sneek: later tell civodul but if there is an additional with-exception-handler within the exception handler, that doesn't augment the captured exception handler stack to which inner exceptions will dispatch <wingo>sneek: later tell civodul the fix will be small but also gnarly :P will take some thinking. there are funny interactions with delimited continuations ***taw10_ is now known as taw10
<jpoiret>that's unfortunate (but at the same time it's great we now know why this happens) <jpoiret>i believe it could lead to many hard to debug errors including file corruption and whatnot <wingo>my goodness that is indeed a bug, jpoiret :) <wingo>jpoiret: briefly: if pipe2 is useful, we should import it via gnulib <wingo>then we don't have to #ifdef in dup2_handle_error <jpoiret>the only difference with pipe is that it can atomically set O_CLOEXEC iirc <wingo>sure. gnulib provides a portable wrapper that is probably non-atomic on non-linux <wingo>which is probably sufficient, dunno <jpoiret>i didn't know about gnulib until very recently <wingo>yeah it's a funny system but it has made guile maintenance easier <jpoiret>i'm not a fan of the replacement here though <wingo>actually it would seem we already have pipe2 from gnulib <wingo>so, nothing to do there. you can just use it <jpoiret>pipe2 is supposed to actually be atomic, that's the whole point, i wouldn't want to pretend we're using pipe2 everywhere when we actually can't <wingo>(i checked lib/Makefile.am for the set of gnulib modules we use) <jpoiret>i'm not sure it would help readability <antipode>Is there a list of unmodified gnulib files? <jpoiret>rather, in the meantime, i ended up coding a guile extension for guix that actually does roughly the same, but using posix_spawn, would you prefer that? that means less maintenance burden in the future <antipode>Those are bundling and hence should ideally be removed from a packaging perspective, if not in upstream then in the downstream distro (in case of Guix, in a snippet, and regenerated from gnulib in a phase). <wingo>jpoiret: not sure! i looked into posix_spawn at one point and given that we needed fork for single-threaded cases, decided maybe best to keep what we had (though evidently i messed it up :P) <antipode>If O_CLOEXEC were the default, then things like 'start_child' could be done a bit simpler ... <jpoiret>antipode: that's an OS design issue, unfortunately <jpoiret>wingo: I mean, posix_spawn basically uses fork under the hood, no? <jpoiret>for system* and friends i'd say it's the ideal interface <wingo>& because we have to use fork directly for other things, no point in trying to use posix_spawn; but perhaps i misremember <antipode>Wasn't on the Hurd and some BSD posix_spawn implemented separately, without using 'fork' + 'exec'? <jpoiret>maybe Gnulib even uses CreateProcess or whatever win32 magic exists which would be optimal <jpoiret>wingo: we could use both though, no? <jpoiret>fork when its full power is needed, but posix_spawn for safety where appropriate <jpoiret>i've looked at the libc implementation of posix_spawn, and it's definitely well done and not something we'd want to replicate <wingo>(& using it in guile for system* makes total sense to me!) <jpoiret>great! i'll try to send a new patch series today using it instead <jpoiret>the one thing troubling me is that we need to add a close action for *every* open fd since that's what the system* semantics are right now <civodul>the exception handler stack capture story does seem tricky <jpoiret>as antipode said, would it be welcome to unbundle the gnulib from the repo? <jpoiret>ie, removing the lib/ directory, and adding the gnulib-tool invocation to autogen.sh ***taylan2 is now known as taylan
<civodul>jpoiret: Gnulib is a "source library", it's meant to be bundled <civodul>for the purposes of easing portability to other systems, it makes sense to do it this way <civodul>but then of course i understand the arguments against it <civodul>but we're not gonna rewrite Gnulib or anything like that i think :-) <jpoiret>i think the main blocker for that is gnulib not making releases <civodul>yes, but that's consistent with the spirit of how it's meant to be used <civodul>it's not a "library" in the usual sense of the word <jpoiret>it's as much of a library as Rust libraries, i'd simply call it vendoring <civodul>well, it started as a way of sharing portability snippets <civodul>like replacements for obscure C functions that may or may not be available <civodul>instead of copy/pasting them, you'd import them with gnulib-tool <jpoiret>which has the same upsides/downsides as copy-pasting <jpoiret>except you have an updater tool, right <jpoiret>how do i add a gnulib module to guile? <jpoiret>i've tried `./gnulib-tool --add-import posix_spawn` inside the guile top-level directory but i get "Ambiguity: to which directory should the modules be added? Please specify at least --m4-base=..." <civodul>i've kinda forgotten the details, some sort of selective amnesia :-) <civodul>introducing posix_spawn may be a good idea <civodul>note that there's another option to achieve a similar effect: using/exposing/augmenting the thing that open-pipe uses <jpoiret>that's exactly what i had done prior <jpoiret>but this is very complicated to get right <jpoiret>especially in the presence of threads <jpoiret>but posix_spawn is way better at this <civodul>scm_piped_process is an attempt to provide a safe fork+exec primitive <jpoiret>and lets us stop worrying about maintaining some low-level code <civodul>jpoiret: oh nice, i hadn't seen this patch series! <jpoiret>scm_pipe_process is broken currently <jpoiret>the reason behind the inferior lockups :) <jpoiret>it also has a couple of other bugs that are pretty serious, outlined in the op of the bug report <civodul>so what's your recommendation right now? applying the patch set above, or switching to posix_spawn? <jpoiret>switching to posix_spawn from gnulib i guess <jpoiret>that's what we discussed this morning with wingo <jpoiret>when i figure out how to add the gnulib module 😳 <civodul>great that you're looking into that, it's a pretty fundamental feature... <jpoiret>i wonder how many pipe-to-subprogram bugs went undiagnosed all this time <jpoiret>given how it popped up instantly when i tried to log stdout and stderr of a program to the same pipe <jpoiret>well, it seems to be working once i specified the default `--m4-base=m4` 🤷 ***reyman_aw is now known as reyman
***reyman is now known as reyman_aw
***reyman_aw is now known as reyman
***rgherdt_ is now known as rgherdt
***reyman is now known as reyman_aw
<lloda>is there a general way to generate hash-proc from equal-proc for srfi-69 make-hash-table? atm i'm defining both in terms of f like (lambda (a b) (equal? (f a) (f b))) and (lambda (a s) (hash (f a) s)) but i'm not very happy with this ***lampilelo_ is now known as lampilelo