86 lines
3.6 KiB
HTML
86 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: <a rel="previous" accesskey="p" href="Implementation-warts.html#Implementation-warts">Implementation warts</a>,
|
||
|
|
Up: <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>
|
||
|
|
|