[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62691: Calling system* in the module body hangs Guile, while calling
bug#62691: Calling system* in the module body hangs Guile, while calling open-pipe* does not
Sun, 09 Apr 2023 01:58:48 -0600
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Михаил Бахтерев <firstname.lastname@example.org> writes:
> Greetings! I've hit the following issue.
> 4. When loading (i am not sure about the stage) module which contains
> in the body system* call Guile hangs on futex operation. The code to
> reproduce the behavior.
> $ cat a.scm
> (add-to-load-path ".")
> (import (b))
> (display "hello world from SCM!")
> $ cat b.scm
> (define-module (b))
> (system* "echo" "hello world from SYS!")
> $ guile a.scm
> HANGS HERE!
It hangs for me, too. It turns out that Guile cannot start its signal
handling thread during module resolution. A slightly simpler reproducer
can be obtained by replacing the call to ‘system*’ with:
(sigaction SIGINT SIG_DFL)
It doesn’t matter which signal or how it’s handled, just that calling
‘sigaction’ forces Guile to start the signal handling thread. (The
reason ‘system*’ hangs is that it calls ‘sigaction’ under the hood.)
If I’m reading everything right, this is because Guile uses
‘call-with-new-thread’ to start the signal handling thread. That
procedure creates a new thread, and among other things, sets an object
property on the thread :
(set! (thread-join-data thread) (cons cv mutex))
However, setting the object property requires module resolution, since
the above expands to:
(((@@ (guile) setter) thread-join-data) thread (cons cv mutex))
;; ^^^^^^^^^^^^^^^^^ Module resolution.
At this point, we have two threads. The first one is holding the
“autoload” lock (acquired during module resolution) and is trying to
start the signal handling thread. It ends up waiting for the signal
thread to indicate that it started :
(wait-condition-variable cv mutex)
The second thread is trying to acquire the “autoload” lock so that it
can set its ‘thread-join-data’ property (by resolving ‘setter’). It
won’t signal that it has started until it does so.
The two threads are deadlocked.
A simple fix would be to use the underlying ‘setter’ generic directly:
(setter thread-join-data thread (cons cv mutex))
It’s hard to read (IMO), but maybe with a comment it’s good enough.
For now it’s best to simply avoid calling ‘system*’ at the top level of
 See ‘call-with-new-thread’ in “module/ice-9/threads.scm”.