From 168c38234b184f4b600db64f77af0749fde33c10 Mon Sep 17 00:00:00 2001
From: Volker Haspel <volker.haspel@linutronix.de>
Date: Fri, 11 Jan 2019 15:07:42 +0100
Subject: new slide set for using signals in linux

Signed-off-by: Volker Haspel <volker.haspel@linutronix.de>
---
 application-devel/signals/pres_signals_en.tex | 171 ++++++++++++++++++++++++++
 1 file changed, 171 insertions(+)
 create mode 100644 application-devel/signals/pres_signals_en.tex

(limited to 'application-devel/signals/pres_signals_en.tex')

diff --git a/application-devel/signals/pres_signals_en.tex b/application-devel/signals/pres_signals_en.tex
new file mode 100644
index 0000000..6540b3b
--- /dev/null
+++ b/application-devel/signals/pres_signals_en.tex
@@ -0,0 +1,171 @@
+\input{configpres}
+
+\def\lximg{/usr/share/lx/icons/fueller.png}
+
+\subsection{Linux Signals}
+
+\title{Linux Signals}
+\maketitle
+
+% stop displaying 'fueller.png' on the following slides
+\def\lximg{none}
+
+\begin{frame}
+\tableofcontents
+\end{frame}
+
+\subsubsection{Introduction}
+\begin{frame}
+\frametitle{Signal Introduction}
+What is a signal:
+\begin{itemize}
+\item Used to control processes
+\item Easy communication instrument between processes
+\item A signal is an asynchronous event
+\item "Interrupt at process level"
+\end{itemize}
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{available signals}
+kill -l shows all available signals on the system
+\begin{lstlisting}
+kill -l
+ 1) SIGHUP       2) SIGINT      3) SIGQUIT     4) SIGILL      5) SIGTRAP
+ 6) SIGABRT      7) SIGBUS      8) SIGFPE      9) SIGKILL    10) SIGUSR1
+11) SIGSEGV     12) SIGUSR2    13) SIGPIPE    14) SIGALRM    15) SIGTERM
+16) SIGSTKFLT   17) SIGCHLD    18) SIGCONT    19) SIGSTOP    20) SIGTSTP
+21) SIGTTIN     22) SIGTTOU    23) SIGURG     24) SIGXCPU    25) SIGXFSZ
+26) SIGVTALRM   27) SIGPROF    28) SIGWINCH   29) SIGIO      30) SIGPWR
+...
+\end{lstlisting}
+
+General description:
+\begin{lstlisting}
+man 7 signal
+\end{lstlisting}
+\end{frame}
+
+\begin{frame}
+\frametitle{process a signal}
+If the process receives a signal, the process has to tell the Kernel what to do with it.
+Three possibilities are available how a signal can be disposed:
+\begin{itemize}
+\item ignore it: we do nothing. Most of the signals can be ignored but signals generated by hardware exceptions like divide by zero, if ignored can have weird consequences.
+\item we take care: The process has to registers a function. This function is called by kernel when that signal occurs.
+\item we call the default disposition: Every signal has a default action. This could be process terminate, ignore etc.
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{special signals}
+Two signals cannot be caught:
+\begin{itemize}
+\item SIGKILL
+\item SIGSTOP
+\end{itemize}
+\end{frame}
+
+\subsubsection{Example}
+\begin{frame}[fragile]
+\frametitle{simple signal example (2)}
+Necessary include files:
+\begin{lstlisting}
+#include<stdio.h>
+#include<signal.h>
+#include<unistd.h>
+\end{lstlisting}
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{simple signal example (2)}
+Signal handler:
+\begin{lstlisting}
+void sig_handler(int signo)
+{
+  if (signo == SIGINT)
+    printf("received SIGINT\n");
+}
+\end{lstlisting}
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{simple signal example (3)}
+main() function of our example:
+\begin{lstlisting}
+int main(void)
+{
+  if (signal(SIGINT, sig_handler) == SIG_ERR)
+    printf("\ncan't catch SIGINT\n");
+  // A long long wait so that we can easily issue a signal to this process
+  while(1)
+    sleep(1);
+  return 0;
+}
+\end{lstlisting}
+\end{frame}
+
+\begin{frame}[fragile]
+\frametitle{simple signal example (4)}
+run our small example
+\begin{lstlisting}
+./sigfunc
+^Creceived SIGINT
+^Creceived SIGINT
+^Creceived SIGINT
+^Creceived SIGINT
+\end{lstlisting}
+We tried the key combination ctrl+c several times but each time the process didn’t terminate. This is because the signal was handled in the code and this was confirmed from the print we got on each line.
+\end{frame}
+
+\begin{frame}
+\frametitle{send signals}
+Two possibilities for sending a signal:
+\begin{itemize}
+\item kill() - send a signal to a process
+\item raise() - send a signal to the caller
+\end{itemize}
+\end{frame}
+
+\subsubsection{Pitfalls}
+\begin{frame}
+\frametitle{signal handler must be reentrant}
+Reentrant means: The function can be stopped in between due to any reason (like due to interrupt or signal) and then can be reentered again safely before its previous invocations complete the execution.
+
+\bigskip
+Reason: Signals are asynchronous events. It could be possible the signal occurs again before the signal handler is still called.
+\end{frame}
+
+\begin{frame}
+\frametitle{system calls return if a signal occur}
+If a signal is send to a process, all system calls return. The complete application must be able to handle the return values and check error codes, if the system call was interrupted:
+\begin{itemize}
+\item EINTR
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{signal handler should not block}
+The signal handler is called by the Kernel. It is not allowed to block or wait for a event in the signal handler.
+\end{frame}
+
+\begin{frame}
+\frametitle{signals and threads}
+pthreads(7) describes that POSIX.1 requires all threads in a process share attributes, including: signal dispositions
+
+\bigskip
+This mean: it is not clear from which thread the signal handler is called!
+\end{frame}
+
+\subsubsection{Alternative}
+\begin{frame}
+\frametitle{Signals should not be used}
+Use other mechanismen like:
+\begin{itemize}
+\item files
+\item pipes
+\item pthreads
+\end{itemize}
+\end{frame}
+
+\input{tailpres}
-- 
cgit v1.2.3

