98 lines
4.4 KiB
HTML
98 lines
4.4 KiB
HTML
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>Implementation warts - 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="The-deferral-mechanism.html#The-deferral-mechanism" title="The deferral mechanism">
|
||
|
|
<link rel="next" href="Programming-with-signal-handling-in-mind.html#Programming-with-signal-handling-in-mind" title="Programming with signal handling in mind">
|
||
|
|
<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="Implementation-warts"></a>
|
||
|
|
Next: <a rel="next" accesskey="n" href="Programming-with-signal-handling-in-mind.html#Programming-with-signal-handling-in-mind">Programming with signal handling in mind</a>,
|
||
|
|
Previous: <a rel="previous" accesskey="p" href="The-deferral-mechanism.html#The-deferral-mechanism">The deferral mechanism</a>,
|
||
|
|
Up: <a rel="up" accesskey="u" href="Signal-handling.html#Signal-handling">Signal handling</a>
|
||
|
|
<hr>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h3 class="section">6.3 Implementation warts</h3>
|
||
|
|
|
||
|
|
<h4 class="subsection">6.3.1 RT signals</h4>
|
||
|
|
|
||
|
|
<p>Sending and receiving the same number of signals is crucial for
|
||
|
|
<code>INTERRUPT-THREAD</code> and <code>sig_stop_for_gc</code>, hence they are
|
||
|
|
real-time signals for which the kernel maintains a queue as opposed to
|
||
|
|
just setting a flag for “sigint pending”.
|
||
|
|
|
||
|
|
<p>Note, however, that the rt signal queue is finite and on current linux
|
||
|
|
kernels a system wide resource. If the queue is full, SBCL tries to
|
||
|
|
signal until it succeeds. This behaviour can lead to deadlocks, if a
|
||
|
|
thread in a <code>WITHOUT-INTERRUPTS</code> is interrupted many times,
|
||
|
|
filling up the queue and then a gc hits and tries to send
|
||
|
|
<code>SIG_STOP_FOR_GC</code>.
|
||
|
|
|
||
|
|
<h4 class="subsection">6.3.2 Miscellaneous issues</h4>
|
||
|
|
|
||
|
|
<p>Signal handlers should automatically restore errno and fp
|
||
|
|
state. Currently, this is not the case.
|
||
|
|
|
||
|
|
<h4 class="subsection">6.3.3 POSIX – Letter and Spirit</h4>
|
||
|
|
|
||
|
|
<p>POSIX restricts signal handlers to a use only a narrow subset of POSIX
|
||
|
|
functions, and declares anything else to have undefined semantics.
|
||
|
|
|
||
|
|
<p>Apparently the real reason is that a signal handler is potentially
|
||
|
|
interrupting a POSIX call: so the signal safety requirement is really
|
||
|
|
a re-entrancy requirement. We can work around the letter of the
|
||
|
|
standard by arranging to handle the interrupt when the signal handler
|
||
|
|
returns (see: <code>arrange_return_to_lisp_function</code>.) This does,
|
||
|
|
however, in no way protect us from the real issue of re-entrancy: even
|
||
|
|
though we would no longer be in a signal handler, we might still be in
|
||
|
|
the middle of an interrupted POSIX call.
|
||
|
|
|
||
|
|
<p>For some signals this appears to be a non-issue: <code>SIGSEGV</code> and
|
||
|
|
other semi-synchronous signals are raised by our code for our code,
|
||
|
|
and so we can be sure that we are not interrupting a POSIX call with
|
||
|
|
any of them.
|
||
|
|
|
||
|
|
<p>For asynchronous signals like <code>SIGALARM</code> and <code>SIGINT</code> this
|
||
|
|
is a real issue.
|
||
|
|
|
||
|
|
<p>The right thing to do in multithreaded builds would probably be to use
|
||
|
|
POSIX semaphores (which are signal safe) to inform a separate handler
|
||
|
|
thread about such asynchronous events. In single-threaded builds there
|
||
|
|
does not seem to be any other option aside from generally blocking
|
||
|
|
asynch signals and listening for them every once and a while at safe
|
||
|
|
points. Neither of these is implemented as of SBCL 1.0.4.
|
||
|
|
|
||
|
|
<p>Currently all our handlers invoke unsafe functions without hesitation.
|
||
|
|
|
||
|
|
</body></html>
|
||
|
|
|