Commit | Line | Data |
3aeed370 |
1 | package Thread::Signal; |
2 | use Thread qw(async); |
3 | |
28b605d8 |
4 | our $VERSION = '1.00'; |
5 | |
3aeed370 |
6 | =head1 NAME |
7 | |
3087ffe5 |
8 | Thread::Signal - Start a thread which runs signal handlers reliably (for old code) |
9 | |
10 | =head1 CAVEAT |
11 | |
12 | For new code the use of the C<Thread::Signal> module is discouraged and |
13 | the direct use of the C<threads> and associated modules is encouraged instead. |
14 | |
15 | However, there is no direct equivalent of the Thread::Signal module in the |
16 | new implementation of threads. On the bright side: signals are now delivered |
17 | reliably to Perl programs that do not use threads. The handling of signals |
18 | with the new threading features is up to the underlying thread implementation |
19 | that is being used and may therefor be less reliable. |
20 | |
21 | If you want to specify a thread-specific signal, you can alter the %SIG hash |
22 | in the thread where you want to handle a signal differently from other threads. |
23 | This at least seems to work under Linux. But there are no guarantees and your |
24 | mileage may vary. |
25 | |
26 | For the whole story about the development of threads in Perl, and why you |
27 | should B<not> be using this module unless you know what you're doing, see the |
28 | CAVEAT of the C<Thread> module. |
3aeed370 |
29 | |
30 | =head1 SYNOPSIS |
31 | |
32 | use Thread::Signal; |
33 | |
34 | $SIG{HUP} = \&some_handler; |
35 | |
36 | =head1 DESCRIPTION |
37 | |
38 | The C<Thread::Signal> module starts up a special signal handler thread. |
39 | All signals to the process are delivered to it and it runs the |
40 | associated C<$SIG{FOO}> handlers for them. Without this module, |
41 | signals arriving at inopportune moments (such as when perl's internals |
42 | are in the middle of updating critical structures) cause the perl |
43 | code of the handler to be run unsafely which can cause memory corruption |
44 | or worse. |
45 | |
46 | =head1 BUGS |
47 | |
48 | This module changes the semantics of signal handling slightly in that |
49 | the signal handler is run separately from the main thread (and in |
50 | parallel with it). This means that tricks such as calling C<die> from |
51 | a signal handler behave differently (and, in particular, can't be |
52 | used to exit directly from a system call). |
53 | |
54 | =cut |
55 | |
56 | if (!init_thread_signals()) { |
57 | require Carp; |
58 | Carp::croak("init_thread_signals failed: $!"); |
59 | } |
60 | |
61 | async { |
62 | my $sig; |
63 | while ($sig = await_signal()) { |
64 | &$sig(); |
65 | } |
66 | }; |
67 | |
68 | END { |
69 | kill_sighandler_thread(); |
70 | } |
71 | |
72 | 1; |