emacs.d/clones/www.sbcl.org/sbcl-internals/Programming-with-signal-handling-in-mind.html
2023-01-18 20:30:47 +01:00

85 lines
3.6 KiB
HTML

<html lang="en">
<head>
<title>Programming with signal handling in mind - SBCL Internals</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="SBCL Internals">
<meta name="generator" content="makeinfo 4.11">
<link title="Top" rel="start" href="index.html#Top">
<link rel="up" href="Signal-handling.html#Signal-handling" title="Signal handling">
<link rel="prev" href="Implementation-warts.html#Implementation-warts" title="Implementation warts">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
<!--
This manual is part of the SBCL software system. See the `README'
file for more information.
This manual is in the public domain and is provided with
absolutely no warranty. See the `COPYING' and `CREDITS' files for
more information.
-->
<meta http-equiv="Content-Style-Type" content="text/css">
<style type="text/css"><!--
pre.display { font-family:inherit }
pre.format { font-family:inherit }
pre.smalldisplay { font-family:inherit; font-size:smaller }
pre.smallformat { font-family:inherit; font-size:smaller }
pre.smallexample { font-size:smaller }
pre.smalllisp { font-size:smaller }
span.sc { font-variant:small-caps }
span.roman { font-family:serif; font-weight:normal; }
span.sansserif { font-family:sans-serif; font-weight:normal; }
--></style>
</head>
<body>
<div class="node">
<p>
<a name="Programming-with-signal-handling-in-mind"></a>
Previous:&nbsp;<a rel="previous" accesskey="p" href="Implementation-warts.html#Implementation-warts">Implementation warts</a>,
Up:&nbsp;<a rel="up" accesskey="u" href="Signal-handling.html#Signal-handling">Signal handling</a>
<hr>
</div>
<h3 class="section">6.4 Programming with signal handling in mind</h3>
<h4 class="subsection">6.4.1 On reentrancy</h4>
<p>Since they might be invoked in the middle of just about anything,
signal handlers must invoke only reentrant functions or async signal
safe functions to be more precise. Functions passed to
<code>INTERRUPT-THREAD</code> have the same restrictions and considerations
as signal handlers.
<p>Destructive modification, and holding mutexes to protect desctructive
modifications from interfering with each other are often the cause of
non-reentrancy. Recursive locks are not likely to help, and while
<code>WITHOUT-INTERRUPTS</code> is, it is considered untrendy to litter the
code with it.
<p>Some basic functionality, such as streams and the debugger are
intended to be reentrant, but not much effort has been spent on
verifying it.
<h4 class="subsection">6.4.2 More deadlocks</h4>
<p>If functions A and B directly or indirectly lock mutexes M and N, they
should do so in the same order to avoid deadlocks.
<p>A less trivial scenario is where there is only one lock involved but
it is acquired in a <code>WITHOUT-GCING</code> in thread A, and outside of
<code>WITHOUT-GCING</code> in thread B. If thread A has entered
<code>WITHOUT-GCING</code> but thread B has the lock when the gc hits, then
A cannot leave <code>WITHOUT-GCING</code> because it is waiting for the lock
the already suspended thread B has. From this scenario one can easily
derive the rule: in a <code>WITHOUT-GCING</code> form (or pseudo atomic for
that matter) never wait for another thread that's not in
<code>WITHOUT-GCING</code>.
<h4 class="subsection">6.4.3 Calling user code</h4>
<p>For the reasons above, calling user code, i.e. functions passed in, or
in other words code that one cannot reason about, from non-reentrant
code (holding locks), <code>WITHOUT-INTERRUPTS</code>, <code>WITHOUT-GCING</code>
is dangerous and best avoided.
</body></html>