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 Implementing race-free signal handling

This example uses a single event pipe for all signals, and one
Async::Interrupt per signal. This code is actually what the L<AnyEvent>
module uses itself when Async::Interrupt is available.

First, create the event pipe and hook it into the event loop

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

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         => $signum,
      pipe           => [$SIGPIPE->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";
         }
      }
   }

=head2 Interrupt perl from another thread

This example interrupts the Perl interpreter from another thread, via the
XS API. This is used by e.g. the L<EV::Loop::Async> module.

#TODO#

=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, otherwise, PL_sig_pending
   # etc. will be null pointers.
   $SIG{KILL} = sub { };

   our $VERSION = '1.0';

   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 signal_hysteresis => $boolean

Sets the initial signal hysteresis state, see the C<signal_hysteresis>
method, below.

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

=item pipe_autodrain => $boolean

Sets the initial autodrain state, see the C<pipe_autodrain> method, below.

=back

=cut

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

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

   # urgs, reminds me of Event
   for my $attr (qw(pipe_autodrain signal_hysteresis)) {
      $self->$attr ($arg{$attr}) if exists $arg{$attr};
   }

   $self
}

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