guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Are there any way to mimic Bash's exit traps in Guile?


From: Mark H Weaver
Subject: Re: Are there any way to mimic Bash's exit traps in Guile?
Date: Sat, 25 May 2019 06:23:09 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi,

Михаил Бахтерев <address@hidden> writes:

> I use in one of my bash-scripts the following construction
>
>   trap "kill -s TERM 0" EXIT
>
> to terminate all spawned processes when master process exits or is
> aborted by any reason. Is equivalent technique possible in Guile?

Guile doesn't provide anything like this out-of-the-box, but you should
be able to accomplish something similar in Guile by installing signal
handlers for all terminating signals, and additionally wrapping the main
program within (catch #t ...).  This should catch most exit modes,
including calls within Scheme to 'exit' or 'quit'.

However, it should be noted that Guile provides many ways to exit a
process immediately without unwinding the stack, notably
'primitive-exit' and 'primitive-_exit'.  The signal handlers that you
install for terminating signals should probably call 'primitive-exit'
after killing the subprocesses.

Also note there's a synchronization detail worth paying attention to
here.  The signal handler must be able to safely access the current list
of spawned processes.

In a single threaded program, or more generally, if only one thread
needs to access the list of spawned processes, then it should suffice to
arrange for the Guile terminating signal handlers to run within the same
thread (see the last optional argument to 'sigaction' in Guile).  In
this case, you shouldn't need locks to protect the list of spawned
processes.  You can use 'call-with-blocked-asyncs' to prevent Guile
signal handlers from being run during critical sections when the list is
being modified.

If multiple threads must access the list of spawned processes, then you
will also need to protect it with a mutex.  However, you must guard
against the case that the Guile signal handler interrupts an existing
thread that's already holding the mutex and is within a critical
section.  This case can be avoided by locking the mutex only within
'call-with-blocked-asyncs'.

      Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]