When we works on threaded applications nothing causes more
fear or confusion than the issue of handling signals, because signals are a low-level
BSD(Berkeley Software Distribution) mechanism that can be used to deliver information to a process or
manipulate it in some way. Some programs use signals to detect certain events,
such as the death of a child process. The system uses signals to terminate
runaway processes and communicate other types of information.
The problem with signals is not what they do, but their
behavior when your application has multiple threads. In a single-threaded
application, all signal handlers run on the main thread. In a multithreaded
application, signals that are not tied to a specific hardware error (such as an
illegal instruction) are delivered to whichever thread happens to be running at
the time. If multiple threads are running simultaneously, the signal is
delivered to whichever one the system happens to pick. In other words, signals
can be delivered to any thread of your application.
The first rule for implementing signal handlers
in applications is to avoid assumptions about which thread is handling the
signal. If a specific thread wants to handle a given signal, you need to work
out some way of notifying that thread when the signal arrives. You cannot just
assume that installation of a signal handler from that thread will result in
the signal being delivered to the same thread.
Join MindStick Community
You need to log in or register to vote on answers or questions.
We use cookies to ensure you have the best browsing experience on our website. By using our site, you
acknowledge that you have read and understood our
Cookie Policy &
Privacy Policy.
When we works on threaded applications nothing causes more fear or confusion than the issue of handling signals, because signals are a low-level BSD(Berkeley Software Distribution) mechanism that can be used to deliver information to a process or manipulate it in some way. Some programs use signals to detect certain events, such as the death of a child process. The system uses signals to terminate runaway processes and communicate other types of information.
The problem with signals is not what they do, but their behavior when your application has multiple threads. In a single-threaded application, all signal handlers run on the main thread. In a multithreaded application, signals that are not tied to a specific hardware error (such as an illegal instruction) are delivered to whichever thread happens to be running at the time. If multiple threads are running simultaneously, the signal is delivered to whichever one the system happens to pick. In other words, signals can be delivered to any thread of your application.
The first rule for implementing signal handlers in applications is to avoid assumptions about which thread is handling the signal. If a specific thread wants to handle a given signal, you need to work out some way of notifying that thread when the signal arrives. You cannot just assume that installation of a signal handler from that thread will result in the signal being delivered to the same thread.