Hi,
Josselin Poiret skribis:
> Yes, I believe this is all taken care of by our use of posix_spawn
> (which was the point in the first place :) ).
Yup! I pushed the fix as 4ae33f76d6b33ea0bedfa36050d44c88d08c2823.
Thanks,
Ludo’.
Hi Ludo,
Ludovic Courtès writes:
> Unless I’m mistaken, we can remove the ‘scm_dynwind_sigaction’ calls
> from ‘scm_system_star’: now that we use ‘posix_spawn’, this is all taken
> care of.
>
> This can be seen by running:
>
> strace -o /tmp/log.strace -f guile -c '(system* "/bin/sh" "-c" "ech
Hi,
Mikael Djurfeldt skribis:
> system* temporarily re-binds signal handlers to prevent the child process
> from killing the parent. Thus, it is not thread safe with regard to SIGINT
> (or SIGQUIT if available). So, your code has a race condition with respect
> to the signal handler. This common
system* temporarily re-binds signal handlers to prevent the child process
from killing the parent. Thus, it is not thread safe with regard to SIGINT
(or SIGQUIT if available). So, your code has a race condition with respect
to the signal handler. This common resource can, in principle, be handled
t
I've encountered a situation where signal handlers don't seem to
run. With the following program, sending it SIGINT won't trigger the
handler, however if you remove the system* call, then the handler will
run.
(use-modules (ice-9 threads))
(call-with-new-thread
(lambda ()
;; Remove th
