ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/cvsroot/Async-Interrupt/Interrupt.pm
(Generate patch)

Comparing cvsroot/Async-Interrupt/Interrupt.pm (file contents):
Revision 1.1 by root, Thu Jul 2 13:41:44 2009 UTC vs.
Revision 1.15 by root, Fri Jul 17 14:59:47 2009 UTC

7 use Async::Interrupt; 7 use Async::Interrupt;
8 8
9=head1 DESCRIPTION 9=head1 DESCRIPTION
10 10
11This module implements a single feature only of interest to advanced perl 11This module implements a single feature only of interest to advanced perl
12modules, namely asynchronous interruptions (think "unix signals", which 12modules, namely asynchronous interruptions (think "UNIX signals", which
13are very similar). 13are very similar).
14 14
15Sometimes, modules wish to run code asynchronously (in another thread), 15Sometimes, modules wish to run code asynchronously (in another thread,
16and then signal the perl interpreter on certain events. One common way is 16or from a signal handler), and then signal the perl interpreter on
17to write some data to a pipe and use an event handling toolkit to watch 17certain events. One common way is to write some data to a pipe and use an
18for I/O events. Another way is to send a signal. Those methods are slow, 18event handling toolkit to watch for I/O events. Another way is to send
19and in the case of a pipe, also not asynchronous - it won't interrupt a 19a signal. Those methods are slow, and in the case of a pipe, also not
20running perl interpreter. 20asynchronous - it won't interrupt a running perl interpreter.
21 21
22This module implements asynchronous notifications that enable you to 22This module implements asynchronous notifications that enable you to
23signal running perl code form another thread, asynchronously, without 23signal running perl code from another thread, asynchronously, and
24issuing syscalls. 24sometimes even without using a single syscall.
25
26=head2 USAGE SCENARIOS
25 27
26=over 4 28=over 4
27 29
30=item Race-free signal handling
31
32There seems to be no way to do race-free signal handling in perl: to
33catch a signal, you have to execute Perl code, and between entering the
34interpreter C<select> function (or other blocking functions) and executing
35the select syscall is a small but relevant timespan during which signals
36will be queued, but perl signal handlers will not be executed and the
37blocking syscall will not be interrupted.
38
39You can use this module to bind a signal to a callback while at the same
40time activating an event pipe that you can C<select> on, fixing the race
41completely.
42
43This can be used to implement the signal hadling in event loops,
44e.g. L<AnyEvent>, L<POE>, L<IO::Async::Loop> and so on.
45
46=item Background threads want speedy reporting
47
48Assume you want very exact timing, and you can spare an extra cpu core
49for that. Then you can run an extra thread that signals your perl
50interpreter. This means you can get a very exact timing source while your
51perl code is number crunching, without even using a syscall to communicate
52between your threads.
53
54For example the deliantra game server uses a variant of this technique
55to interrupt background processes regularly to send map updates to game
56clients.
57
58L<IO::AIO> and L<BDB> could also use this to speed up result reporting.
59
60=item Speedy event loop invocation
61
62One could use this module e.g. in L<Coro> to interrupt a running coro-thread
63and cause it to enter the event loop.
64
65Or one could bind to C<SIGIO> and tell some important sockets to send this
66signal, causing the event loop to be entered to reduce network latency.
67
68=back
69
70=head2 HOW TO USE
71
72You can use this module by creating an C<Async::Interrupt> object for each
73such event source. This object stores a perl and/or a C-level callback
74that is invoked when the C<Async::Interrupt> object gets signalled. It is
75executed at the next time the perl interpreter is running (i.e. it will
76interrupt a computation, but not an XS function or a syscall).
77
78You can signal the C<Async::Interrupt> object either by calling it's C<<
79->signal >> method, or, more commonly, by calling a C function. There is
80also the built-in (POSIX) signal source.
81
82The C<< ->signal_func >> returns the address of the C function that is to
83be called (plus an argument to be used during the call). The signalling
84function also takes an integer argument in the range SIG_ATOMIC_MIN to
85SIG_ATOMIC_MAX (guaranteed to allow at least 0..127).
86
87Since this kind of interruption is fast, but can only interrupt a
88I<running> interpreter, there is optional support for signalling a pipe
89- that means you can also wait for the pipe to become readable (e.g. via
90L<EV> or L<AnyEvent>). This, of course, incurs the overhead of a C<read>
91and C<write> syscall.
92
93=over 4
94
28=cut 95=cut
29 96
30package Async::Interrupt; 97package Async::Interrupt;
31 98
99use common::sense;
100
32BEGIN { 101BEGIN {
102 # the next line forces initialisation of internal
103 # signal handling # variables
104 $SIG{KILL} = sub { };
105
33 $VERSION = '0.02'; 106 our $VERSION = '0.501';
34 107
35 require XSLoader; 108 require XSLoader;
36 XSLoader::load Async::Interrupt::, $VERSION; 109 XSLoader::load ("Async::Interrupt", $VERSION);
37} 110}
111
112our $DIED = sub { warn "$@" };
38 113
39=item $async = new Async::Interrupt key => value... 114=item $async = new Async::Interrupt key => value...
40 115
41Creates a new Async::Interrupt object. You may only use async 116Creates a new Async::Interrupt object. You may only use async
42notifications on this object while it exists, so you need to keep a 117notifications on this object while it exists, so you need to keep a
51 126
52Registers a perl callback to be invoked whenever the async interrupt is 127Registers a perl callback to be invoked whenever the async interrupt is
53signalled. 128signalled.
54 129
55Note that, since this callback can be invoked at basically any time, it 130Note that, since this callback can be invoked at basically any time, it
56must not modify any well-known global variables such as C<$/>, C<$@> or 131must not modify any well-known global variables such as C<$/> without
57C<$!>, without restoring them again before returning. 132restoring them again before returning.
58 133
134The exceptions are C<$!> and C<$@>, which are saved and restored by
135Async::Interrupt.
136
137If the callback should throw an exception, then it will be caught,
138and C<$Async::Interrupt::DIED> will be called with C<$@> containing
139the exception. The default will simply C<warn> about the message and
140continue.
141
59=item c_cb => [$c_func, $c_data] 142=item c_cb => [$c_func, $c_arg]
60 143
61Registers a C callback the be invoked whenever the async interrupt is 144Registers a C callback the be invoked whenever the async interrupt is
62signalled. 145signalled.
63 146
64The C callback must have the following prototype: 147The C callback must have the following prototype:
65 148
66 void c_func (pTHX_ void *c_data, int value); 149 void c_func (pTHX_ void *c_arg, int value);
67 150
68Both C<$c_func> and C<$c_data> must be specified as integers/IVs. 151Both C<$c_func> and C<$c_arg> must be specified as integers/IVs, and
152C<$value> is the C<value> passed to some earlier call to either C<$signal>
153or the C<signal_func> function.
69 154
70Note that, because the callback can be invoked at almost any time, you 155Note that, because the callback can be invoked at almost any time, you
71have to be careful at saving and restoring global variables that Perl 156have to be careful at saving and restoring global variables that Perl
72might use, most notably C<errno>. The callback itself runs as part of the 157might use (the exception is C<errno>, which is saved and restored by
73perl context, so you can call any perl functions and modify any perl data 158Async::Interrupt). The callback itself runs as part of the perl context,
74structures. 159so you can call any perl functions and modify any perl data structures (in
160which case the requirements set out for C<cb> apply as well).
75 161
76=item fh => $fileno_or_fh 162=item var => $scalar_ref
77 163
164When specified, then the given argument must be a reference to a
165scalar. The scalar will be set to C<0> intiially. Signalling the interrupt
166object will set it to the passed value, handling the interrupt will reset
167it to C<0> again.
168
169Note that the only thing you are legally allowed to do is to is to check
170the variable in a boolean or integer context (e.g. comparing it with a
171string, or printing it, will I<destroy> it and might cause your program to
172crash or worse).
173
174=item signal => $signame_or_value
175
176When this parameter is specified, then the Async::Interrupt will hook the
177given signal, that is, it will effectively call C<< ->signal (0) >> each time
178the given signal is caught by the process.
179
180Only one async can hook a given signal, and the signal will be restored to
181defaults when the Async::Interrupt object gets destroyed.
182
183=item pipe => [$fileno_or_fh_for_reading, $fileno_or_fh_for_writing]
184
78Specifies a file descriptor (or file handle) that should be signalled 185Specifies two file descriptors (or file handles) that should be signalled
79whenever the async interrupt is signalled. This means a single octet will 186whenever the async interrupt is signalled. This means a single octet will
80be written to it, and before the callback is being invoked, it will be 187be written to it, and before the callback is being invoked, it will be
81read again. Due to races, it is unlikely but possible that multiple octets 188read again. Due to races, it is unlikely but possible that multiple octets
82are written, therefore, it is recommended that the file handle is in 189are written. It is required that the file handles are both in nonblocking
83nonblocking mode. 190mode.
84 191
85(You can get a portable pipe and set non-blocking mode portably by using
86e.g. L<AnyEvent::Util> from the L<AnyEvent> distro).
87
88The object will keep a reference to the file handle. 192The object will keep a reference to the file handles.
89 193
90This can be used to ensure that async notifications will interrupt event 194This can be used to ensure that async notifications will interrupt event
91frameworks as well. 195frameworks as well.
92 196
197Note that C<Async::Interrupt> will create a suitable signal fd
198automatically when your program requests one, so you don't have to specify
199this agrument when all you want is an extra file descriptor to watch.
200
93=back 201=back
94 202
95=cut 203=cut
96 204
97sub new { 205sub new {
98 my ($class, %arg) = @_; 206 my ($class, %arg) = @_;
99 207
100 my $self = _alloc $arg{cb}, @{$arg{c_cb}}[0,1], $arg{fh}; 208 bless \(_alloc $arg{cb}, @{$arg{c_cb}}[0,1], @{$arg{pipe}}[0,1], $arg{signal}, $arg{var}), $class
101 bless \$self, $class
102} 209}
103 210
104=item ($signal_func, $signal_arg) = $async->signal_cb 211=item ($signal_func, $signal_arg) = $async->signal_func
105 212
106Returns the address of a function to call asynchronously. The function has 213Returns the address of a function to call asynchronously. The function has
107the following prototype and needs to be passed the specified C<$c_arg>, 214the following prototype and needs to be passed the specified C<$c_arg>,
108which is a C<void *> cast to C<IV>: 215which is a C<void *> cast to C<IV>:
109 216
111 218
112An example call would look like: 219An example call would look like:
113 220
114 signal_func (signal_arg, 0); 221 signal_func (signal_arg, 0);
115 222
116The function is safe toc all from within signal and thread contexts, at 223The function is safe to call from within signal and thread contexts, at
117any time. The specified C<value> is passed to both C and Perl callback. 224any time. The specified C<value> is passed to both C and Perl callback.
225
226C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
227(1..127 is portable).
118 228
119If the function is called while the Async::Interrupt object is already 229If the function is called while the Async::Interrupt object is already
120signaled but before the callbacks are being executed, then the stored 230signaled but before the callbacks are being executed, then the stored
121C<value> is being overwritten. Due to the asynchronous nature of the code, 231C<value> is either the old or the new one. Due to the asynchronous
122the C<value> can even be passed to two consecutive invocations of the 232nature of the code, the C<value> can even be passed to two consecutive
123callback. 233invocations of the callback.
124 234
235=item $address = $async->c_var
236
237Returns the address (cast to IV) of an C<IV> variable. The variable is set
238to C<0> initially and gets set to the passed value whenever the object
239gets signalled, and reset to C<0> once the interrupt has been handled.
240
241Note that it is often beneficial to just call C<PERL_ASYNC_CHECK ()> to
242handle any interrupts.
243
244Example: call some XS function to store the address, then show C code
245waiting for it.
246
247 my_xs_func $async->c_var;
248
249 static IV *valuep;
250
251 void
252 my_xs_func (void *addr)
253 CODE:
254 valuep = (IV *)addr;
255
256 // code in a loop, waiting
257 while (!*valuep)
258 ; // do soemthing
259
125=item $async->signal ($value=0) 260=item $async->signal ($value=1)
126 261
127This signals the given async object from Perl code. Semi-obviously, this 262This signals the given async object from Perl code. Semi-obviously, this
128will instantly trigger the callback invocation. 263will instantly trigger the callback invocation.
129 264
265C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
266(1..127 is portable).
267
268=item $async->block
269
270=item $async->unblock
271
272Sometimes you need a "critical section" of code that will not be
273interrupted by an Async::Interrupt. This can be implemented by calling C<<
274$async->block >> before the critical section, and C<< $async->unblock >>
275afterwards.
276
277Note that there must be exactly one call of C<unblock> for every previous
278call to C<block> (i.e. calls can nest).
279
280Since ensuring this in the presence of exceptions and threads is
281usually more difficult than you imagine, I recommend using C<<
282$async->scoped_block >> instead.
283
284=item $async->scope_block
285
286This call C<< $async->block >> and installs a handler that is called when
287the current scope is exited (via an exception, by canceling the Coro
288thread, by calling last/goto etc.).
289
290This is the recommended (and fastest) way to implement critical sections.
291
292=item $async->pipe_enable
293
294=item $async->pipe_disable
295
296Enable/disable signalling the pipe when the interrupt occurs (default is
297enabled). Writing to a pipe is relatively expensive, so it can be disabled
298when you know you are not waiting for it (for example, with L<EV> you
299could disable the pipe in a check watcher, and enable it in a prepare
300watcher).
301
302Note that currently, while C<pipe_disable> is in effect, no attempt to
303read from the pipe will be done when handling events. This might change as
304soon as I realize why this is a mistake.
305
306=item $fileno = $async->pipe_fileno
307
308Returns the reading side of the signalling pipe. If no signalling pipe is
309currently attached to the object, it will dynamically create one.
310
311Note that the only valid oepration on this file descriptor is to wait
312until it is readable. The fd might belong currently to a pipe, a tcp
313socket, or an eventfd, depending on the platform, and is guaranteed to be
314C<select>able.
315
316=item $async->post_fork
317
318The object will not normally be usable after a fork (as the pipe fd is
319shared between processes). Calling this method after a fork in the child
320ensures that the object will work as expected again. It only needs to be
321called when the async object is used in the child.
322
323This only works when the pipe was created by Async::Interrupt.
324
325Async::Interrupt ensures that the reading file descriptor does not change
326it's value.
327
130=cut 328=cut
131 329
1321; 3301;
133 331
134=back 332=back
333
334=head1 EXAMPLE
335
336There really should be a complete C/XS example. Bug me about it. Better
337yet, create one.
338
339=head1 IMPLEMENTATION DETAILS AND LIMITATIONS
340
341This module works by "hijacking" SIGKILL, which is guaranteed to always
342exist, but also cannot be caught, so is always available.
343
344Basically, this module fakes the occurance of a SIGKILL signal and
345then intercepts the interpreter handling it. This makes normal signal
346handling slower (probably unmeasurably, though), but has the advantage
347of not requiring a special runops function, nor slowing down normal perl
348execution a bit.
349
350It assumes that C<sig_atomic_t>, C<int> and C<IV> are all async-safe to
351modify.
135 352
136=head1 AUTHOR 353=head1 AUTHOR
137 354
138 Marc Lehmann <schmorp@schmorp.de> 355 Marc Lehmann <schmorp@schmorp.de>
139 http://home.schmorp.de/ 356 http://home.schmorp.de/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines