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.

Or L<EV::Loop::Async> uses an interrupt object to wake up perl when new
events have arrived.

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.

=head1 USAGE EXAMPLES

=head2 Async::Interrupt to implement race-free signal handling

This example uses a single event pipe for all signals, and one
Async::Interrupt per signal.

First, create the event pipe and hook it into the event loop (this code is
actually what L<AnyEvent> uses itself):

   $SIGPIPE = new Async::Interrupt::EventPipe;
   $SIGPIPE_W = AnyEvent->io (
      fh   => $SIGPIPE->fileno,
      poll => "r",
      cb   => \&_signal_check,
   );

Then, for each signal to hook, create an Async::Interrupt object. The
callback just sets a global variable, as we are only interested in
synchronous signals (i.e. when the event loop polls), which is why the
pipe draining is not done automatically.

   my $interrupt = new Async::Interrupt
      cb             => sub { undef $SIGNAL_RECEIVED{$signum} }
      signal         => $signal,
      pipe           => [$SIGPIPE_R->filenos],
      pipe_autodrain => 0,
   ;

Finally, the I/O callback for the event pipe handles the signals:

   sub _signal_check {
      # drain the pipe first
      $SIGPIPE->drain;

      # two loops, just to be sure
      while (%SIGNAL_RECEIVED) {
         for (keys %SIGNAL_RECEIVED) {
            delete $SIGNAL_RECEIVED{$_};
            warn "signal $_ received\n";
         }
      }
   }


=head1 THE Async::Interrupt CLASS

=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.6';

   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> initially. 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 argument when all you want is an extra file descriptor to watch.

If you want to share a single event pipe between multiple Async::Interrupt
objects, you can use the C<Async::Interrupt::EventPipe> class to manage
those.

=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<$signal_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 something

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

This signals the given async object from Perl code. Semi-obviously, this
will instantly trigger the callback invocation (it does not, as the name
might imply, do anything with POSIX signals).

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

=item $async->signal_hysteresis ($enable)

Enables or disables signal hysteresis (default: disabled). If a POSIX
signal is used as a signal source for the interrupt object, then enabling
signal hysteresis causes Async::Interrupt to reset the signal action to
C<SIG_IGN> in the signal handler and restore it just before handling the
interruption.

When you expect a lot of signals (e.g. when using SIGIO), then enabling
signal hysteresis can reduce the number of handler invocations
considerably, at the cost of two extra syscalls.

Note that setting the signal to C<SIG_IGN> can have unintended side
effects when you fork and exec other programs, as often they do nto expect
signals to be ignored by default.

=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 ($block_func, $block_arg) = $async->scope_block_func

Returns the address of a function that implements the C<scope_block>
functionality.

It has the following prototype and needs to be passed the specified
C<$block_arg>, which is a C<void *> cast to C<IV>:

   void (*block_func) (void *block_arg)

An example call would look like:

   block_func (block_arg);

The function is safe to call only from within the toplevel of a perl XS
function and will call C<LEAVE> and C<ENTER> (in this order!).

=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->pipe_autodrain ($enable)

Enables (C<1>) or disables (C<0>) automatic draining of the pipe (default:
enabled). When automatic draining is enabled, then Async::Interrupt will
automatically clear the pipe. Otherwise the user is responsible for this
draining.

This is useful when you want to share one pipe among many Async::Interrupt
objects.

=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.

=item $signum = Async::Interrupt::sig2num $signame_or_number

=item $signame = Async::Interrupt::sig2name $signame_or_number

These two convenience functions simply convert a signal name or number to
the corresponding name or number. They are not used by this module and
exist just because perl doesn't have a nice way to do this on its own.

They will return C<undef> on illegal names or numbers.

=back

=head1 THE Async::Interrupt::EventPipe CLASS

Pipes are the predominent utility to make asynchronous signals
synchronous. However, pipes are hard to come by: they don't exist on the
broken windows platform, and on GNU/Linux systems, you might want to use
an C<eventfd> instead.

This class creates selectable event pipes in a portable fashion: on
windows, it will try to create a tcp socket pair, on GNU/Linux, it will
try to create an eventfd and everywhere else it will try to use a normal
pipe.

=over 4

=item $epipe = new Async::Interrupt::EventPipe

This creates and returns an eventpipe object. This object is simply a
blessed array reference:

=item ($r_fd, $w_fd) = $epipe->filenos

Returns the read-side file descriptor and the write-side file descriptor.

Example: pass an eventpipe object as pipe to the Async::Interrupt
constructor, and create an AnyEvent watcher for the read side.

   my $epipe = new Async::Interrupt::EventPipe;
   my $asy = new Async::Interrupt pipe => [$epipe->filenos];
   my $iow = AnyEvent->io (fh => $epipe->fileno, poll => 'r', cb => sub { });

=item $r_fd = $epipe->fileno

Return only the reading/listening side.

=item $epipe->signal

Write something to the pipe, in a portable fashion.

=item $epipe->drain

Drain (empty) the pipe.

=item $epipe->renew

Recreates the pipe (useful after a fork). The reading side will not change
it's file descriptor number, but the writing side might.

=back

=cut

1;

=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.18
Committed:	Tue Jul 28 12:50:16 2009 UTC (14 years, 10 months ago) by root
Branch:	MAIN
Changes since 1.17:	+56 -0 lines
Log Message:	* empty log message *
#	Content
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	modules, namely asynchronous interruptions (think "UNIX signals", which
13	are very similar).
14
15	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
22	This module implements asynchronous notifications that enable you to
23	signal running perl code from another thread, asynchronously, and
24	sometimes even without using a single syscall.
25
26	=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	Or L<EV::Loop::Async> uses an interrupt object to wake up perl when new
59	events have arrived.
60
61	L<IO::AIO> and L<BDB> could also use this to speed up result reporting.
62
63	=item Speedy event loop invocation
64
65	One could use this module e.g. in L<Coro> to interrupt a running coro-thread
66	and cause it to enter the event loop.
67
68	Or one could bind to C<SIGIO> and tell some important sockets to send this
69	signal, causing the event loop to be entered to reduce network latency.
70
71	=back
72
73	=head2 HOW TO USE
74
75	You can use this module by creating an C<Async::Interrupt> object for each
76	such event source. This object stores a perl and/or a C-level callback
77	that is invoked when the C<Async::Interrupt> object gets signalled. It is
78	executed at the next time the perl interpreter is running (i.e. it will
79	interrupt a computation, but not an XS function or a syscall).
80
81	You can signal the C<Async::Interrupt> object either by calling it's C<<
82	->signal >> method, or, more commonly, by calling a C function. There is
83	also the built-in (POSIX) signal source.
84
85	The C<< ->signal_func >> returns the address of the C function that is to
86	be called (plus an argument to be used during the call). The signalling
87	function also takes an integer argument in the range SIG_ATOMIC_MIN to
88	SIG_ATOMIC_MAX (guaranteed to allow at least 0..127).
89
90	Since this kind of interruption is fast, but can only interrupt a
91	I<running> interpreter, there is optional support for signalling a pipe
92	- that means you can also wait for the pipe to become readable (e.g. via
93	L<EV> or L<AnyEvent>). This, of course, incurs the overhead of a C<read>
94	and C<write> syscall.
95
96	=head1 USAGE EXAMPLES
97
98	=head2 Async::Interrupt to implement race-free signal handling
99
100	This example uses a single event pipe for all signals, and one
101	Async::Interrupt per signal.
102
103	First, create the event pipe and hook it into the event loop (this code is
104	actually what L<AnyEvent> uses itself):
105
106	$SIGPIPE = new Async::Interrupt::EventPipe;
107	$SIGPIPE_W = AnyEvent->io (
108	fh => $SIGPIPE->fileno,
109	poll => "r",
110	cb => \&_signal_check,
111	);
112
113	Then, for each signal to hook, create an Async::Interrupt object. The
114	callback just sets a global variable, as we are only interested in
115	synchronous signals (i.e. when the event loop polls), which is why the
116	pipe draining is not done automatically.
117
118	my $interrupt = new Async::Interrupt
119	cb => sub { undef $SIGNAL_RECEIVED{$signum} }
120	signal => $signal,
121	pipe => [$SIGPIPE_R->filenos],
122	pipe_autodrain => 0,
123	;
124
125	Finally, the I/O callback for the event pipe handles the signals:
126
127	sub _signal_check {
128	# drain the pipe first
129	$SIGPIPE->drain;
130
131	# two loops, just to be sure
132	while (%SIGNAL_RECEIVED) {
133	for (keys %SIGNAL_RECEIVED) {
134	delete $SIGNAL_RECEIVED{$_};
135	warn "signal $_ received\n";
136	}
137	}
138	}
139
140
141
142	=head1 THE Async::Interrupt CLASS
143
144	=over 4
145
146	=cut
147
148	package Async::Interrupt;
149
150	use common::sense;
151
152	BEGIN {
153	# the next line forces initialisation of internal
154	# signal handling # variables
155	$SIG{KILL} = sub { };
156
157	our $VERSION = '0.6';
158
159	require XSLoader;
160	XSLoader::load ("Async::Interrupt", $VERSION);
161	}
162
163	our $DIED = sub { warn "$@" };
164
165	=item $async = new Async::Interrupt key => value...
166
167	Creates a new Async::Interrupt object. You may only use async
168	notifications on this object while it exists, so you need to keep a
169	reference to it at all times while it is used.
170
171	Optional constructor arguments include (normally you would specify at
172	least one of C<cb> or C<c_cb>).
173
174	=over 4
175
176	=item cb => $coderef->($value)
177
178	Registers a perl callback to be invoked whenever the async interrupt is
179	signalled.
180
181	Note that, since this callback can be invoked at basically any time, it
182	must not modify any well-known global variables such as C<$/> without
183	restoring them again before returning.
184
185	The exceptions are C<$!> and C<$@>, which are saved and restored by
186	Async::Interrupt.
187
188	If the callback should throw an exception, then it will be caught,
189	and C<$Async::Interrupt::DIED> will be called with C<$@> containing
190	the exception. The default will simply C<warn> about the message and
191	continue.
192
193	=item c_cb => [$c_func, $c_arg]
194
195	Registers a C callback the be invoked whenever the async interrupt is
196	signalled.
197
198	The C callback must have the following prototype:
199
200	void c_func (pTHX_ void *c_arg, int value);
201
202	Both C<$c_func> and C<$c_arg> must be specified as integers/IVs, and
203	C<$value> is the C<value> passed to some earlier call to either C<$signal>
204	or the C<signal_func> function.
205
206	Note that, because the callback can be invoked at almost any time, you
207	have to be careful at saving and restoring global variables that Perl
208	might use (the exception is C<errno>, which is saved and restored by
209	Async::Interrupt). The callback itself runs as part of the perl context,
210	so you can call any perl functions and modify any perl data structures (in
211	which case the requirements set out for C<cb> apply as well).
212
213	=item var => $scalar_ref
214
215	When specified, then the given argument must be a reference to a
216	scalar. The scalar will be set to C<0> initially. Signalling the interrupt
217	object will set it to the passed value, handling the interrupt will reset
218	it to C<0> again.
219
220	Note that the only thing you are legally allowed to do is to is to check
221	the variable in a boolean or integer context (e.g. comparing it with a
222	string, or printing it, will I<destroy> it and might cause your program to
223	crash or worse).
224
225	=item signal => $signame_or_value
226
227	When this parameter is specified, then the Async::Interrupt will hook the
228	given signal, that is, it will effectively call C<< ->signal (0) >> each time
229	the given signal is caught by the process.
230
231	Only one async can hook a given signal, and the signal will be restored to
232	defaults when the Async::Interrupt object gets destroyed.
233
234	=item pipe => [$fileno_or_fh_for_reading, $fileno_or_fh_for_writing]
235
236	Specifies two file descriptors (or file handles) that should be signalled
237	whenever the async interrupt is signalled. This means a single octet will
238	be written to it, and before the callback is being invoked, it will be
239	read again. Due to races, it is unlikely but possible that multiple octets
240	are written. It is required that the file handles are both in nonblocking
241	mode.
242
243	The object will keep a reference to the file handles.
244
245	This can be used to ensure that async notifications will interrupt event
246	frameworks as well.
247
248	Note that C<Async::Interrupt> will create a suitable signal fd
249	automatically when your program requests one, so you don't have to specify
250	this argument when all you want is an extra file descriptor to watch.
251
252	If you want to share a single event pipe between multiple Async::Interrupt
253	objects, you can use the C<Async::Interrupt::EventPipe> class to manage
254	those.
255
256	=back
257
258	=cut
259
260	sub new {
261	my ($class, %arg) = @_;
262
263	bless \(_alloc $arg{cb}, @{$arg{c_cb}}[0,1], @{$arg{pipe}}[0,1], $arg{signal}, $arg{var}), $class
264	}
265
266	=item ($signal_func, $signal_arg) = $async->signal_func
267
268	Returns the address of a function to call asynchronously. The function
269	has the following prototype and needs to be passed the specified
270	C<$signal_arg>, which is a C<void *> cast to C<IV>:
271
272	void (signal_func) (void signal_arg, int value)
273
274	An example call would look like:
275
276	signal_func (signal_arg, 0);
277
278	The function is safe to call from within signal and thread contexts, at
279	any time. The specified C<value> is passed to both C and Perl callback.
280
281	C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
282	(1..127 is portable).
283
284	If the function is called while the Async::Interrupt object is already
285	signaled but before the callbacks are being executed, then the stored
286	C<value> is either the old or the new one. Due to the asynchronous
287	nature of the code, the C<value> can even be passed to two consecutive
288	invocations of the callback.
289
290	=item $address = $async->c_var
291
292	Returns the address (cast to IV) of an C<IV> variable. The variable is set
293	to C<0> initially and gets set to the passed value whenever the object
294	gets signalled, and reset to C<0> once the interrupt has been handled.
295
296	Note that it is often beneficial to just call C<PERL_ASYNC_CHECK ()> to
297	handle any interrupts.
298
299	Example: call some XS function to store the address, then show C code
300	waiting for it.
301
302	my_xs_func $async->c_var;
303
304	static IV *valuep;
305
306	void
307	my_xs_func (void *addr)
308	CODE:
309	valuep = (IV *)addr;
310
311	// code in a loop, waiting
312	while (!*valuep)
313	; // do something
314
315	=item $async->signal ($value=1)
316
317	This signals the given async object from Perl code. Semi-obviously, this
318	will instantly trigger the callback invocation (it does not, as the name
319	might imply, do anything with POSIX signals).
320
321	C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
322	(1..127 is portable).
323
324	=item $async->signal_hysteresis ($enable)
325
326	Enables or disables signal hysteresis (default: disabled). If a POSIX
327	signal is used as a signal source for the interrupt object, then enabling
328	signal hysteresis causes Async::Interrupt to reset the signal action to
329	C<SIG_IGN> in the signal handler and restore it just before handling the
330	interruption.
331
332	When you expect a lot of signals (e.g. when using SIGIO), then enabling
333	signal hysteresis can reduce the number of handler invocations
334	considerably, at the cost of two extra syscalls.
335
336	Note that setting the signal to C<SIG_IGN> can have unintended side
337	effects when you fork and exec other programs, as often they do nto expect
338	signals to be ignored by default.
339
340	=item $async->block
341
342	=item $async->unblock
343
344	Sometimes you need a "critical section" of code that will not be
345	interrupted by an Async::Interrupt. This can be implemented by calling C<<
346	$async->block >> before the critical section, and C<< $async->unblock >>
347	afterwards.
348
349	Note that there must be exactly one call of C<unblock> for every previous
350	call to C<block> (i.e. calls can nest).
351
352	Since ensuring this in the presence of exceptions and threads is
353	usually more difficult than you imagine, I recommend using C<<
354	$async->scoped_block >> instead.
355
356	=item $async->scope_block
357
358	This call C<< $async->block >> and installs a handler that is called when
359	the current scope is exited (via an exception, by canceling the Coro
360	thread, by calling last/goto etc.).
361
362	This is the recommended (and fastest) way to implement critical sections.
363
364	=item ($block_func, $block_arg) = $async->scope_block_func
365
366	Returns the address of a function that implements the C<scope_block>
367	functionality.
368
369	It has the following prototype and needs to be passed the specified
370	C<$block_arg>, which is a C<void *> cast to C<IV>:
371
372	void (block_func) (void block_arg)
373
374	An example call would look like:
375
376	block_func (block_arg);
377
378	The function is safe to call only from within the toplevel of a perl XS
379	function and will call C<LEAVE> and C<ENTER> (in this order!).
380
381	=item $async->pipe_enable
382
383	=item $async->pipe_disable
384
385	Enable/disable signalling the pipe when the interrupt occurs (default is
386	enabled). Writing to a pipe is relatively expensive, so it can be disabled
387	when you know you are not waiting for it (for example, with L<EV> you
388	could disable the pipe in a check watcher, and enable it in a prepare
389	watcher).
390
391	Note that currently, while C<pipe_disable> is in effect, no attempt to
392	read from the pipe will be done when handling events. This might change as
393	soon as I realize why this is a mistake.
394
395	=item $fileno = $async->pipe_fileno
396
397	Returns the reading side of the signalling pipe. If no signalling pipe is
398	currently attached to the object, it will dynamically create one.
399
400	Note that the only valid oepration on this file descriptor is to wait
401	until it is readable. The fd might belong currently to a pipe, a tcp
402	socket, or an eventfd, depending on the platform, and is guaranteed to be
403	C<select>able.
404
405	=item $async->pipe_autodrain ($enable)
406
407	Enables (C<1>) or disables (C<0>) automatic draining of the pipe (default:
408	enabled). When automatic draining is enabled, then Async::Interrupt will
409	automatically clear the pipe. Otherwise the user is responsible for this
410	draining.
411
412	This is useful when you want to share one pipe among many Async::Interrupt
413	objects.
414
415	=item $async->post_fork
416
417	The object will not normally be usable after a fork (as the pipe fd is
418	shared between processes). Calling this method after a fork in the child
419	ensures that the object will work as expected again. It only needs to be
420	called when the async object is used in the child.
421
422	This only works when the pipe was created by Async::Interrupt.
423
424	Async::Interrupt ensures that the reading file descriptor does not change
425	it's value.
426
427	=item $signum = Async::Interrupt::sig2num $signame_or_number
428
429	=item $signame = Async::Interrupt::sig2name $signame_or_number
430
431	These two convenience functions simply convert a signal name or number to
432	the corresponding name or number. They are not used by this module and
433	exist just because perl doesn't have a nice way to do this on its own.
434
435	They will return C<undef> on illegal names or numbers.
436
437	=back
438
439	=head1 THE Async::Interrupt::EventPipe CLASS
440
441	Pipes are the predominent utility to make asynchronous signals
442	synchronous. However, pipes are hard to come by: they don't exist on the
443	broken windows platform, and on GNU/Linux systems, you might want to use
444	an C<eventfd> instead.
445
446	This class creates selectable event pipes in a portable fashion: on
447	windows, it will try to create a tcp socket pair, on GNU/Linux, it will
448	try to create an eventfd and everywhere else it will try to use a normal
449	pipe.
450
451	=over 4
452
453	=item $epipe = new Async::Interrupt::EventPipe
454
455	This creates and returns an eventpipe object. This object is simply a
456	blessed array reference:
457
458	=item ($r_fd, $w_fd) = $epipe->filenos
459
460	Returns the read-side file descriptor and the write-side file descriptor.
461
462	Example: pass an eventpipe object as pipe to the Async::Interrupt
463	constructor, and create an AnyEvent watcher for the read side.
464
465	my $epipe = new Async::Interrupt::EventPipe;
466	my $asy = new Async::Interrupt pipe => [$epipe->filenos];
467	my $iow = AnyEvent->io (fh => $epipe->fileno, poll => 'r', cb => sub { });
468
469	=item $r_fd = $epipe->fileno
470
471	Return only the reading/listening side.
472
473	=item $epipe->signal
474
475	Write something to the pipe, in a portable fashion.
476
477	=item $epipe->drain
478
479	Drain (empty) the pipe.
480
481	=item $epipe->renew
482
483	Recreates the pipe (useful after a fork). The reading side will not change
484	it's file descriptor number, but the writing side might.
485
486	=back
487
488	=cut
489
490	1;
491
492	=head1 EXAMPLE
493
494	There really should be a complete C/XS example. Bug me about it. Better
495	yet, create one.
496
497	=head1 IMPLEMENTATION DETAILS AND LIMITATIONS
498
499	This module works by "hijacking" SIGKILL, which is guaranteed to always
500	exist, but also cannot be caught, so is always available.
501
502	Basically, this module fakes the occurance of a SIGKILL signal and
503	then intercepts the interpreter handling it. This makes normal signal
504	handling slower (probably unmeasurably, though), but has the advantage
505	of not requiring a special runops function, nor slowing down normal perl
506	execution a bit.
507
508	It assumes that C<sig_atomic_t>, C<int> and C<IV> are all async-safe to
509	modify.
510
511	=head1 AUTHOR
512
513	Marc Lehmann <schmorp@schmorp.de>
514	http://home.schmorp.de/
515
516	=cut
517