Async-Interrupt/Interrupt.pm

=head1 NAME

Async::Interrupt - allow C/XS libraries to interrupt perl asynchronously

=head1 SYNOPSIS

 use Async::Interrupt;

=head1 DESCRIPTION

This module implements a single feature only of interest to advanced perl
modules, namely asynchronous interruptions (think "UNIX signals", which
are very similar).

Sometimes, modules wish to run code asynchronously (in another thread,
or from a signal handler), and then signal the perl interpreter on
certain events. One common way is to write some data to a pipe and use an
event handling toolkit to watch for I/O events. Another way is to send
a signal. Those methods are slow, and in the case of a pipe, also not
asynchronous - it won't interrupt a running perl interpreter.

This module implements asynchronous notifications that enable you to
signal running perl code from another thread, asynchronously, and
sometimes even without using a single syscall.

=head2 USAGE SCENARIOS

=over 4

=item Race-free signal handling

There seems to be no way to do race-free signal handling in perl: to
catch a signal, you have to execute Perl code, and between entering the
interpreter C<select> function (or other blocking functions) and executing
the select syscall is a small but relevant timespan during which signals
will be queued, but perl signal handlers will not be executed and the
blocking syscall will not be interrupted.

You can use this module to bind a signal to a callback while at the same
time activating an event pipe that you can C<select> on, fixing the race
completely.

This can be used to implement the signal hadling in event loops,
e.g. L<AnyEvent>, L<POE>, L<IO::Async::Loop> and so on.

=item Background threads want speedy reporting

Assume you want very exact timing, and you can spare an extra cpu core
for that. Then you can run an extra thread that signals your perl
interpreter. This means you can get a very exact timing source while your
perl code is number crunching, without even using a syscall to communicate
between your threads.

For example the deliantra game server uses a variant of this technique
to interrupt background processes regularly to send map updates to game
clients.

L<IO::AIO> and L<BDB> could also use this to speed up result reporting.

=item Speedy event loop invocation

One could use this module e.g. in L<Coro> to interrupt a running coro-thread
and cause it to enter the event loop.

Or one could bind to C<SIGIO> and tell some important sockets to send this
signal, causing the event loop to be entered to reduce network latency.

=back

=head2 HOW TO USE

You can use this module by creating an C<Async::Interrupt> object for each
such event source. This object stores a perl and/or a C-level callback
that is invoked when the C<Async::Interrupt> object gets signalled. It is
executed at the next time the perl interpreter is running (i.e. it will
interrupt a computation, but not an XS function or a syscall).

You can signal the C<Async::Interrupt> object either by calling it's C<<
->signal >> method, or, more commonly, by calling a C function. There is
also the built-in (POSIX) signal source.

The C<< ->signal_func >> returns the address of the C function that is to
be called (plus an argument to be used during the call). The signalling
function also takes an integer argument in the range SIG_ATOMIC_MIN to
SIG_ATOMIC_MAX (guaranteed to allow at least 0..127).

Since this kind of interruption is fast, but can only interrupt a
I<running> interpreter, there is optional support for signalling a pipe
- that means you can also wait for the pipe to become readable (e.g. via
L<EV> or L<AnyEvent>). This, of course, incurs the overhead of a C<read>
and C<write> syscall.

=over 4

=cut

package Async::Interrupt;

use common::sense;

BEGIN {
   # the next line forces initialisation of internal
   # signal handling # variables
   $SIG{KILL} = sub { };

   our $VERSION = '0.042';

   require XSLoader;
   XSLoader::load ("Async::Interrupt", $VERSION);
}

our $DIED = sub { warn "$@" };

=item $async = new Async::Interrupt key => value...

Creates a new Async::Interrupt object. You may only use async
notifications on this object while it exists, so you need to keep a
reference to it at all times while it is used.

Optional constructor arguments include (normally you would specify at
least one of C<cb> or C<c_cb>).

=over 4

=item cb => $coderef->($value)

Registers a perl callback to be invoked whenever the async interrupt is
signalled.

Note that, since this callback can be invoked at basically any time, it
must not modify any well-known global variables such as C<$/> without
restoring them again before returning.

The exceptions are C<$!> and C<$@>, which are saved and restored by
Async::Interrupt.

If the callback should throw an exception, then it will be caught,
and C<$Async::Interrupt::DIED> will be called with C<$@> containing
the exception.  The default will simply C<warn> about the message and
continue.

=item c_cb => [$c_func, $c_arg]

Registers a C callback the be invoked whenever the async interrupt is
signalled.

The C callback must have the following prototype:

   void c_func (pTHX_ void *c_arg, int value);

Both C<$c_func> and C<$c_arg> must be specified as integers/IVs, and
C<$value> is the C<value> passed to some earlier call to either C<$signal>
or the C<signal_func> function.

Note that, because the callback can be invoked at almost any time, you
have to be careful at saving and restoring global variables that Perl
might use (the exception is C<errno>, which is saved and restored by
Async::Interrupt). The callback itself runs as part of the perl context,
so you can call any perl functions and modify any perl data structures (in
which case the requirements set out for C<cb> apply as well).

=item var => $scalar_ref

When specified, then the given argument must be a reference to a
scalar. The scalar will be set to C<0> intiially. Signalling the interrupt
object will set it to the passed value, handling the interrupt will reset
it to C<0> again.

Note that the only thing you are legally allowed to do is to is to check
the variable in a boolean or integer context (e.g. comparing it with a
string, or printing it, will I<destroy> it and might cause your program to
crash or worse).

=item signal => $signame_or_value

When this parameter is specified, then the Async::Interrupt will hook the
given signal, that is, it will effectively call C<< ->signal (0) >> each time
the given signal is caught by the process.

Only one async can hook a given signal, and the signal will be restored to
defaults when the Async::Interrupt object gets destroyed.

=item pipe => [$fileno_or_fh_for_reading, $fileno_or_fh_for_writing]

Specifies two file descriptors (or file handles) that should be signalled
whenever the async interrupt is signalled. This means a single octet will
be written to it, and before the callback is being invoked, it will be
read again. Due to races, it is unlikely but possible that multiple octets
are written. It is required that the file handles are both in nonblocking
mode.

The object will keep a reference to the file handles.

This can be used to ensure that async notifications will interrupt event
frameworks as well.

Note that C<Async::Interrupt> will create a suitable signal fd
automatically when your program requests one, so you don't have to specify
this agrument when all you want is an extra file descriptor to watch.

=back

=cut

sub new {
   my ($class, %arg) = @_;

   bless \(_alloc $arg{cb}, @{$arg{c_cb}}[0,1], @{$arg{pipe}}[0,1], $arg{signal}, $arg{var}), $class
}

=item ($signal_func, $signal_arg) = $async->signal_func

Returns the address of a function to call asynchronously. The function has
the following prototype and needs to be passed the specified C<$c_arg>,
which is a C<void *> cast to C<IV>:

   void (*signal_func) (void *signal_arg, int value)

An example call would look like:

   signal_func (signal_arg, 0);

The function is safe to call from within signal and thread contexts, at
any time. The specified C<value> is passed to both C and Perl callback.

C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
(1..127 is portable).

If the function is called while the Async::Interrupt object is already
signaled but before the callbacks are being executed, then the stored
C<value> is either the old or the new one. Due to the asynchronous
nature of the code, the C<value> can even be passed to two consecutive
invocations of the callback.

=item $address = $async->c_var

Returns the address (cast to IV) of an C<IV> variable. The variable is set
to C<0> initially and gets set to the passed value whenever the object
gets signalled, and reset to C<0> once the interrupt has been handled.

Note that it is often beneficial to just call C<PERL_ASYNC_CHECK ()> to
handle any interrupts.

Example: call some XS function to store the address, then show C code
waiting for it.

   my_xs_func $async->c_var;

   static IV *valuep;

   void
   my_xs_func (void *addr)
           CODE:
           valuep = (IV *)addr;

   // code in a loop, waiting
   while (!*valuep)
     ; // do soemthing

=item $async->signal ($value=1)

This signals the given async object from Perl code. Semi-obviously, this
will instantly trigger the callback invocation.

C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
(1..127 is portable).

=item $async->block

=item $async->unblock

Sometimes you need a "critical section" of code that will not be
interrupted by an Async::Interrupt. This can be implemented by calling C<<
$async->block >> before the critical section, and C<< $async->unblock >>
afterwards.

Note that there must be exactly one call of C<unblock> for every previous
call to C<block> (i.e. calls can nest).

Since ensuring this in the presence of exceptions and threads is
usually more difficult than you imagine, I recommend using C<<
$async->scoped_block >> instead.

=item $async->scope_block

This call C<< $async->block >> and installs a handler that is called when
the current scope is exited (via an exception, by canceling the Coro
thread, by calling last/goto etc.).

This is the recommended (and fastest) way to implement critical sections.

=item $async->pipe_enable

=item $async->pipe_disable

Enable/disable signalling the pipe when the interrupt occurs (default is
enabled). Writing to a pipe is relatively expensive, so it can be disabled
when you know you are not waiting for it (for example, with L<EV> you
could disable the pipe in a check watcher, and enable it in a prepare
watcher).

Note that currently, while C<pipe_disable> is in effect, no attempt to
read from the pipe will be done when handling events. This might change as
soon as I realize why this is a mistake.

=item $fileno = $async->pipe_fileno

Returns the reading side of the signalling pipe. If no signalling pipe is
currently attached to the object, it will dynamically create one.

Note that the only valid oepration on this file descriptor is to wait
until it is readable. The fd might belong currently to a pipe, a tcp
socket, or an eventfd, depending on the platform, and is guaranteed to be
C<select>able.

=item $async->post_fork

The object will not normally be usable after a fork (as the pipe fd is
shared between processes). Calling this method after a fork in the child
ensures that the object will work as expected again. It only needs to be
called when the async object is used in the child.

This only works when the pipe was created by Async::Interrupt.

Async::Interrupt ensures that the reading file descriptor does not change
it's value.

=cut

1;

=back

=head1 EXAMPLE

There really should be a complete C/XS example. Bug me about it. Better
yet, create one.

=head1 IMPLEMENTATION DETAILS AND LIMITATIONS

This module works by "hijacking" SIGKILL, which is guaranteed to always
exist, but also cannot be caught, so is always available.

Basically, this module fakes the occurance of a SIGKILL signal and
then intercepts the interpreter handling it. This makes normal signal
handling slower (probably unmeasurably, though), but has the advantage
of not requiring a special runops function, nor slowing down normal perl
execution a bit.

It assumes that C<sig_atomic_t>, C<int> and C<IV> are all async-safe to
modify.

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://home.schmorp.de/

=cut

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