[ViewVC] Diff of: cvs/Async-Interrupt/Interrupt.pm

Comparing Async-Interrupt/Interrupt.pm (file contents):
Revision 1.2 by root, Thu Jul 2 15:13:03 2009 UTC vs.
Revision 1.29 by root, Tue Apr 24 20:52:35 2012 UTC

…		…
7	use Async::Interrupt;	7	use Async::Interrupt;
8		8
9	=head1 DESCRIPTION	9	=head1 DESCRIPTION
10		10
11	This module implements a single feature only of interest to advanced perl	11	This module implements a single feature only of interest to advanced perl
12	modules, namely asynchronous interruptions (think "unix signals", which	12	modules, namely asynchronous interruptions (think "UNIX signals", which
13	are very similar).	13	are very similar).
14		14
15	Sometimes, modules wish to run code asynchronously (in another thread),	15	Sometimes, modules wish to run code asynchronously (in another thread,
16	and then signal the perl interpreter on certain events. One common way is	16	or from a signal handler), and then signal the perl interpreter on
17	to write some data to a pipe and use an event handling toolkit to watch	17	certain events. One common way is to write some data to a pipe and use an
18	for I/O events. Another way is to send a signal. Those methods are slow,	18	event handling toolkit to watch for I/O events. Another way is to send
19	and in the case of a pipe, also not asynchronous - it won't interrupt a	19	a signal. Those methods are slow, and in the case of a pipe, also not
20	running perl interpreter.	20	asynchronous - it won't interrupt a running perl interpreter.
21		21
22	This module implements asynchronous notifications that enable you to	22	This module implements asynchronous notifications that enable you to
23	signal running perl code form another thread, asynchronously, without	23	signal running perl code from another thread, asynchronously, and
24	issuing syscalls.	24	sometimes even without using a single syscall.
25		25
26	It works by creating an C<Async::Interrupt> object for each such use. This	26	=head2 USAGE SCENARIOS
27	object stores a perl and/or a C-level callback that is invoked when the	27
28	C<Async::Interrupt> object gets signalled. It is executed at the next time	28	=over 4
29	the perl interpreter is running (i.e. it will interrupt a computation, but	29
30	not an XS function or a syscall).	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).
31		80
32	You can signal the C<Async::Interrupt> object either by calling it's C<<	81	You can signal the C<Async::Interrupt> object either by calling it's C<<
33	->signal >> method, or, more commonly, by calling a C function.	82	->signal >> method, or, more commonly, by calling a C function. There is
		83	also the built-in (POSIX) signal source.
34		84
35	The C<< ->signal_func >> returns the address of the C function that is to	85	The C<< ->signal_func >> returns the address of the C function that is to
36	be called (plus an argument to be used during the call). The signalling	86	be called (plus an argument to be used during the call). The signalling
37	function also takes an integer argument in the range SIG_ATOMIC_MIN to	87	function also takes an integer argument in the range SIG_ATOMIC_MIN to
38	SIG_ATOMIC_MAX (guaranteed to allow at least 0..127).	88	SIG_ATOMIC_MAX (guaranteed to allow at least 0..127).
39		89
40	Since this kind of interruption is fast, but can only interrupt a	90	Since this kind of interruption is fast, but can only interrupt a
41	I<running> interpreter, there is optional support for also signalling a	91	I<running> interpreter, there is optional support for signalling a pipe
42	pipe - that means you can also wait for the pipe to become readable while	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 Implementing race-free signal handling
		99
		100	This example uses a single event pipe for all signals, and one
		101	Async::Interrupt per signal. This code is actually what the L<AnyEvent>
		102	module uses itself when Async::Interrupt is available.
		103
		104	First, create the event pipe and hook it into the event loop
		105
		106	$SIGPIPE = new Async::Interrupt::EventPipe;
		107	$SIGPIPE_W = AnyEvent->io (
		108	fh => $SIGPIPE->fileno,
		109	poll => "r",
		110	cb => \&_signal_check, # defined later
		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 => $signum,
		121	pipe => [$SIGPIPE->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	=head2 Interrupt perl from another thread
		141
		142	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	On the Perl level, a new loop object (which contains the thread)
		146	is created, by first calling some XS constructor, querying the
		147	C-level callback function and feeding that as the C<c_cb> into the
		148	Async::Interrupt constructor:
		149
		150	my $self = XS_thread_constructor;
		151	my ($c_func, $c_arg) = _c_func $self; # return the c callback
		152	my $asy = new Async::Interrupt c_cb => [$c_func, $c_arg];
		153
		154	Then the newly created Interrupt object is queried for the signaling
		155	function that the newly created thread should call, and this is in turn
		156	told to the thread object:
		157
		158	_attach $self, $asy->signal_func;
		159
		160	So to repeat: first the XS object is created, then it is queried for the
		161	callback that should be called when the Interrupt object gets signalled.
		162
		163	Then the interrupt object is queried for the callback fucntion that the
		164	thread should call to signal the Interrupt object, and this callback is
		165	then attached to the thread.
		166
		167	You have to be careful that your new thread is not signalling before the
		168	signal function was configured, for example by starting the background
		169	thread only within C<_attach>.
		170
		171	That concludes the Perl part.
		172
		173	The XS part consists of the actual constructor which creates a thread,
		174	which is not relevant for this example, and two functions, C<_c_func>,
		175	which returns the Perl-side callback, and C<_attach>, which configures
		176	the signalling functioon that is safe toc all from another thread. For
		177	simplicity, we will use global variables to store the functions, normally
		178	you would somehow attach them to C<$self>.
		179
		180	The C<c_func> simply returns the address of a static function and arranges
		181	for the object pointed to by C<$self> to be passed to it, as an integer:
		182
		183	void
		184	_c_func (SV *loop)
		185	PPCODE:
		186	EXTEND (SP, 2);
		187	PUSHs (sv_2mortal (newSViv (PTR2IV (c_func))));
		188	PUSHs (sv_2mortal (newSViv (SvRV (loop))));
		189
		190	This would be the callback (since it runs in a normal Perl context, it is
		191	permissible to manipulate Perl values):
		192
		193	static void
		194	c_func (pTHX_ void *loop_, int value)
		195	{
		196	SV loop_object = (SV )loop_;
		197	...
		198	}
		199
		200	And this attaches the signalling callback:
		201
		202	static void (my_sig_func) (void signal_arg, int value);
		203	static void *my_sig_arg;
		204
		205	void
		206	_attach (SV loop_, IV sig_func, void sig_arg)
		207	CODE:
		208	{
		209	my_sig_func = sig_func;
		210	my_sig_arg = sig_arg;
		211
		212	/* now run the thread */
		213	thread_create (&u->tid, l_run, 0);
		214	}
		215
		216	And C<l_run> (the background thread) would eventually call the signaling
		217	function:
		218
		219	my_sig_func (my_sig_arg, 0);
		220
		221	You can have a look at L<EV::Loop::Async> for an actual example using
		222	intra-thread communication, locking and so on.
		223
		224
		225	=head1 THE Async::Interrupt CLASS
43		226
44	=over 4	227	=over 4
45		228
46	=cut	229	=cut
47		230
48	package Async::Interrupt;	231	package Async::Interrupt;
49		232
50	no warnings;	233	use common::sense;
51		234
52	BEGIN {	235	BEGIN {
		236	# the next line forces initialisation of internal
		237	# signal handling variables, otherwise, PL_sig_pending
		238	# etc. might be null pointers.
		239	$SIG{KILL} = sub { };
		240
53	$VERSION = '0.02';	241	our $VERSION = '1.05';
54		242
55	require XSLoader;	243	require XSLoader;
56	XSLoader::load Async::Interrupt::, $VERSION;	244	XSLoader::load ("Async::Interrupt", $VERSION);
57	}	245	}
58		246
59	our $DIED = sub { warn "$@" };	247	our $DIED = sub { warn "$@" };
60		248
61	=item $async = new Async::Interrupt key => value...	249	=item $async = new Async::Interrupt key => value...
…		…
81	The exceptions are C<$!> and C<$@>, which are saved and restored by	269	The exceptions are C<$!> and C<$@>, which are saved and restored by
82	Async::Interrupt.	270	Async::Interrupt.
83		271
84	If the callback should throw an exception, then it will be caught,	272	If the callback should throw an exception, then it will be caught,
85	and C<$Async::Interrupt::DIED> will be called with C<$@> containing	273	and C<$Async::Interrupt::DIED> will be called with C<$@> containing
86	the exception. The default will simply C<warn> about the message and	274	the exception. The default will simply C<warn> about the message and
87	continue.	275	continue.
88		276
89	=item c_cb => [$c_func, $c_arg]	277	=item c_cb => [$c_func, $c_arg]
90		278
91	Registers a C callback the be invoked whenever the async interrupt is	279	Registers a C callback the be invoked whenever the async interrupt is
…		…
99	C<$value> is the C<value> passed to some earlier call to either C<$signal>	287	C<$value> is the C<value> passed to some earlier call to either C<$signal>
100	or the C<signal_func> function.	288	or the C<signal_func> function.
101		289
102	Note that, because the callback can be invoked at almost any time, you	290	Note that, because the callback can be invoked at almost any time, you
103	have to be careful at saving and restoring global variables that Perl	291	have to be careful at saving and restoring global variables that Perl
104	might use (the excetpion is C<errno>, which is aved and restored by	292	might use (the exception is C<errno>, which is saved and restored by
105	Async::Interrupt). The callback itself runs as part of the perl context,	293	Async::Interrupt). The callback itself runs as part of the perl context,
106	so you can call any perl functions and modify any perl data structures (in	294	so you can call any perl functions and modify any perl data structures (in
107	which case the requireemnts set out for C<cb> apply as well).	295	which case the requirements set out for C<cb> apply as well).
		296
		297	=item var => $scalar_ref
		298
		299	When specified, then the given argument must be a reference to a
		300	scalar. The scalar will be set to C<0> initially. Signalling the interrupt
		301	object will set it to the passed value, handling the interrupt will reset
		302	it to C<0> again.
		303
		304	Note that the only thing you are legally allowed to do is to is to check
		305	the variable in a boolean or integer context (e.g. comparing it with a
		306	string, or printing it, will I<destroy> it and might cause your program to
		307	crash or worse).
		308
		309	=item signal => $signame_or_value
		310
		311	When this parameter is specified, then the Async::Interrupt will hook the
		312	given signal, that is, it will effectively call C<< ->signal (0) >> each time
		313	the given signal is caught by the process.
		314
		315	Only one async can hook a given signal, and the signal will be restored to
		316	defaults when the Async::Interrupt object gets destroyed.
		317
		318	=item signal_hysteresis => $boolean
		319
		320	Sets the initial signal hysteresis state, see the C<signal_hysteresis>
		321	method, below.
108		322
109	=item pipe => [$fileno_or_fh_for_reading, $fileno_or_fh_for_writing]	323	=item pipe => [$fileno_or_fh_for_reading, $fileno_or_fh_for_writing]
110		324
111	Specifies two file descriptors (or file handles) that should be signalled	325	Specifies two file descriptors (or file handles) that should be signalled
112	whenever the async interrupt is signalled. This means a single octet will	326	whenever the async interrupt is signalled. This means a single octet will
113	be written to it, and before the callback is being invoked, it will be	327	be written to it, and before the callback is being invoked, it will be
114	read again. Due to races, it is unlikely but possible that multiple octets	328	read again. Due to races, it is unlikely but possible that multiple octets
115	are written. It is required that the file handles are both in nonblocking	329	are written. It is required that the file handles are both in nonblocking
116	mode.	330	mode.
117		331
118	(You can get a portable pipe and set non-blocking mode portably by using
119	e.g. L<AnyEvent::Util> from the L<AnyEvent> distro).
120
121	The object will keep a reference to the file handles.	332	The object will keep a reference to the file handles.
122		333
123	This can be used to ensure that async notifications will interrupt event	334	This can be used to ensure that async notifications will interrupt event
124	frameworks as well.	335	frameworks as well.
125		336
		337	Note that C<Async::Interrupt> will create a suitable signal fd
		338	automatically when your program requests one, so you don't have to specify
		339	this argument when all you want is an extra file descriptor to watch.
		340
		341	If you want to share a single event pipe between multiple Async::Interrupt
		342	objects, you can use the C<Async::Interrupt::EventPipe> class to manage
		343	those.
		344
		345	=item pipe_autodrain => $boolean
		346
		347	Sets the initial autodrain state, see the C<pipe_autodrain> method, below.
		348
126	=back	349	=back
127		350
128	=cut	351	=cut
129		352
130	sub new {	353	sub new {
131	my ($class, %arg) = @_;	354	my ($class, %arg) = @_;
132		355
133	bless \(_alloc $arg{cb}, @{$arg{c_cb}}[0,1], @{$arg{pipe}}[0,1]), $class	356	my $self = bless \(_alloc $arg{cb}, @{$arg{c_cb}}[0,1], @{$arg{pipe}}[0,1], $arg{signal}, $arg{var}), $class;
		357
		358	# urgs, reminds me of Event
		359	for my $attr (qw(pipe_autodrain signal_hysteresis)) {
		360	$self->$attr ($arg{$attr}) if exists $arg{$attr};
		361	}
		362
		363	$self
134	}	364	}
135		365
136	=item ($signal_func, $signal_arg) = $async->signal_func	366	=item ($signal_func, $signal_arg) = $async->signal_func
137		367
138	Returns the address of a function to call asynchronously. The function has	368	Returns the address of a function to call asynchronously. The function
139	the following prototype and needs to be passed the specified C<$c_arg>,	369	has the following prototype and needs to be passed the specified
140	which is a C<void *> cast to C<IV>:	370	C<$signal_arg>, which is a C<void *> cast to C<IV>:
141		371
142	void (signal_func) (void signal_arg, int value)	372	void (signal_func) (void signal_arg, int value)
143		373
144	An example call would look like:	374	An example call would look like:
145		375
146	signal_func (signal_arg, 0);	376	signal_func (signal_arg, 0);
147		377
148	The function is safe to call from within signal and thread contexts, at	378	The function is safe to call from within signal and thread contexts, at
149	any time. The specified C<value> is passed to both C and Perl callback.	379	any time. The specified C<value> is passed to both C and Perl callback.
150		380
151	C<$value> must be in the valid range for a C<sig_atomic_t> (0..127 is	381	C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
152	portable).	382	(1..127 is portable).
153		383
154	If the function is called while the Async::Interrupt object is already	384	If the function is called while the Async::Interrupt object is already
155	signaled but before the callbacks are being executed, then the stored	385	signaled but before the callbacks are being executed, then the stored
156	C<value> is either the old or the new one. Due to the asynchronous	386	C<value> is either the old or the new one. Due to the asynchronous
157	nature of the code, the C<value> can even be passed to two consecutive	387	nature of the code, the C<value> can even be passed to two consecutive
158	invocations of the callback.	388	invocations of the callback.
159		389
		390	=item $address = $async->c_var
		391
		392	Returns the address (cast to IV) of an C<IV> variable. The variable is set
		393	to C<0> initially and gets set to the passed value whenever the object
		394	gets signalled, and reset to C<0> once the interrupt has been handled.
		395
		396	Note that it is often beneficial to just call C<PERL_ASYNC_CHECK ()> to
		397	handle any interrupts.
		398
		399	Example: call some XS function to store the address, then show C code
		400	waiting for it.
		401
		402	my_xs_func $async->c_var;
		403
		404	static IV *valuep;
		405
		406	void
		407	my_xs_func (void *addr)
		408	CODE:
		409	valuep = (IV *)addr;
		410
		411	// code in a loop, waiting
		412	while (!*valuep)
		413	; // do something
		414
160	=item $async->signal ($value=0)	415	=item $async->signal ($value=1)
161		416
162	This signals the given async object from Perl code. Semi-obviously, this	417	This signals the given async object from Perl code. Semi-obviously, this
163	will instantly trigger the callback invocation.	418	will instantly trigger the callback invocation (it does not, as the name
		419	might imply, do anything with POSIX signals).
164		420
165	C<$value> must be in the valid range for a C<sig_atomic_t> (0..127 is	421	C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
166	portable).	422	(1..127 is portable).
		423
		424	=item $async->signal_hysteresis ($enable)
		425
		426	Enables or disables signal hysteresis (default: disabled). If a POSIX
		427	signal is used as a signal source for the interrupt object, then enabling
		428	signal hysteresis causes Async::Interrupt to reset the signal action to
		429	C<SIG_IGN> in the signal handler and restore it just before handling the
		430	interruption.
		431
		432	When you expect a lot of signals (e.g. when using SIGIO), then enabling
		433	signal hysteresis can reduce the number of handler invocations
		434	considerably, at the cost of two extra syscalls.
		435
		436	Note that setting the signal to C<SIG_IGN> can have unintended side
		437	effects when you fork and exec other programs, as often they do not expect
		438	signals to be ignored by default.
167		439
168	=item $async->block	440	=item $async->block
169		441
170	Sometimes you need a "critical section" of code where
171
172	=item $async->unblock	442	=item $async->unblock
173		443
		444	Sometimes you need a "critical section" of code that will not be
		445	interrupted by an Async::Interrupt. This can be implemented by calling C<<
		446	$async->block >> before the critical section, and C<< $async->unblock >>
		447	afterwards.
		448
		449	Note that there must be exactly one call of C<unblock> for every previous
		450	call to C<block> (i.e. calls can nest).
		451
		452	Since ensuring this in the presence of exceptions and threads is
		453	usually more difficult than you imagine, I recommend using C<<
		454	$async->scoped_block >> instead.
		455
		456	=item $async->scope_block
		457
		458	This call C<< $async->block >> and installs a handler that is called when
		459	the current scope is exited (via an exception, by canceling the Coro
		460	thread, by calling last/goto etc.).
		461
		462	This is the recommended (and fastest) way to implement critical sections.
		463
		464	=item ($block_func, $block_arg) = $async->scope_block_func
		465
		466	Returns the address of a function that implements the C<scope_block>
		467	functionality.
		468
		469	It has the following prototype and needs to be passed the specified
		470	C<$block_arg>, which is a C<void *> cast to C<IV>:
		471
		472	void (block_func) (void block_arg)
		473
		474	An example call would look like:
		475
		476	block_func (block_arg);
		477
		478	The function is safe to call only from within the toplevel of a perl XS
		479	function and will call C<LEAVE> and C<ENTER> (in this order!).
		480
		481	=item $async->pipe_enable
		482
		483	=item $async->pipe_disable
		484
		485	Enable/disable signalling the pipe when the interrupt occurs (default is
		486	enabled). Writing to a pipe is relatively expensive, so it can be disabled
		487	when you know you are not waiting for it (for example, with L<EV> you
		488	could disable the pipe in a check watcher, and enable it in a prepare
		489	watcher).
		490
		491	Note that currently, while C<pipe_disable> is in effect, no attempt to
		492	read from the pipe will be done when handling events. This might change as
		493	soon as I realize why this is a mistake.
		494
		495	=item $fileno = $async->pipe_fileno
		496
		497	Returns the reading side of the signalling pipe. If no signalling pipe is
		498	currently attached to the object, it will dynamically create one.
		499
		500	Note that the only valid operation on this file descriptor is to wait
		501	until it is readable. The fd might belong currently to a pipe, a tcp
		502	socket, or an eventfd, depending on the platform, and is guaranteed to be
		503	C<select>able.
		504
		505	=item $async->pipe_autodrain ($enable)
		506
		507	Enables (C<1>) or disables (C<0>) automatic draining of the pipe (default:
		508	enabled). When automatic draining is enabled, then Async::Interrupt will
		509	automatically clear the pipe. Otherwise the user is responsible for this
		510	draining.
		511
		512	This is useful when you want to share one pipe among many Async::Interrupt
		513	objects.
		514
		515	=item $async->post_fork
		516
		517	The object will not normally be usable after a fork (as the pipe fd is
		518	shared between processes). Calling this method after a fork in the child
		519	ensures that the object will work as expected again. It only needs to be
		520	called when the async object is used in the child.
		521
		522	This only works when the pipe was created by Async::Interrupt.
		523
		524	Async::Interrupt ensures that the reading file descriptor does not change
		525	it's value.
		526
		527	=item $signum = Async::Interrupt::sig2num $signame_or_number
		528
		529	=item $signame = Async::Interrupt::sig2name $signame_or_number
		530
		531	These two convenience functions simply convert a signal name or number to
		532	the corresponding name or number. They are not used by this module and
		533	exist just because perl doesn't have a nice way to do this on its own.
		534
		535	They will return C<undef> on illegal names or numbers.
		536
		537	=back
		538
		539	=head1 THE Async::Interrupt::EventPipe CLASS
		540
		541	Pipes are the predominant utility to make asynchronous signals
		542	synchronous. However, pipes are hard to come by: they don't exist on the
		543	broken windows platform, and on GNU/Linux systems, you might want to use
		544	an C<eventfd> instead.
		545
		546	This class creates selectable event pipes in a portable fashion: on
		547	windows, it will try to create a tcp socket pair, on GNU/Linux, it will
		548	try to create an eventfd and everywhere else it will try to use a normal
		549	pipe.
		550
		551	=over 4
		552
		553	=item $epipe = new Async::Interrupt::EventPipe
		554
		555	This creates and returns an eventpipe object. This object is simply a
		556	blessed array reference:
		557
		558	=item ($r_fd, $w_fd) = $epipe->filenos
		559
		560	Returns the read-side file descriptor and the write-side file descriptor.
		561
		562	Example: pass an eventpipe object as pipe to the Async::Interrupt
		563	constructor, and create an AnyEvent watcher for the read side.
		564
		565	my $epipe = new Async::Interrupt::EventPipe;
		566	my $asy = new Async::Interrupt pipe => [$epipe->filenos];
		567	my $iow = AnyEvent->io (fh => $epipe->fileno, poll => 'r', cb => sub { });
		568
		569	=item $r_fd = $epipe->fileno
		570
		571	Return only the reading/listening side.
		572
		573	=item $epipe->signal
		574
		575	Write something to the pipe, in a portable fashion.
		576
		577	=item $epipe->drain
		578
		579	Drain (empty) the pipe.
		580
		581	=item ($c_func, $c_arg) = $epipe->signal_func
		582
		583	=item ($c_func, $c_arg) = $epipe->drain_func
		584
		585	These two methods returns a function pointer and C<void *> argument
		586	that can be called to have the effect of C<< $epipe->signal >> or C<<
		587	$epipe->drain >>, respectively, on the XS level.
		588
		589	They both have the following prototype and need to be passed their
		590	C<$c_arg>, which is a C<void *> cast to an C<IV>:
		591
		592	void (c_func) (void c_arg)
		593
		594	An example call would look like:
		595
		596	c_func (c_arg);
		597
		598	=item $epipe->renew
		599
		600	Recreates the pipe (useful after a fork). The reading side will not change
		601	it's file descriptor number, but the writing side might.
		602
		603	=item $epipe->wait
		604
		605	This method blocks the process until there are events on the pipe. This is
		606	not a very event-based or ncie way of usign an event pipe, but it can be
		607	occasionally useful.
		608
		609	=back
		610
174	=cut	611	=cut
175		612
176	1;	613	1;
177		614
178	=back
179
180	=head1 EXAMPLE
181
182	#TODO
183
184	=head1 IMPLEMENTATION DETAILS AND LIMITATIONS	615	=head1 IMPLEMENTATION DETAILS AND LIMITATIONS
185		616
186	This module works by "hijacking" SIGKILL, which is guarenteed to be always	617	This module works by "hijacking" SIGKILL, which is guaranteed to always
187	available in perl, but also cannot be caught, so is always available.	618	exist, but also cannot be caught, so is always available.
188		619
189	Basically, this module fakes the receive of a SIGKILL signal and	620	Basically, this module fakes the occurance of a SIGKILL signal and
190	then catches it. This makes normal signal handling slower (probably	621	then intercepts the interpreter handling it. This makes normal signal
191	unmeasurably), but has the advantage of not requiring a special runops nor	622	handling slower (probably unmeasurably, though), but has the advantage
192	slowing down normal perl execution a bit.	623	of not requiring a special runops function, nor slowing down normal perl
		624	execution a bit.
193		625
194	It assumes that C<sig_atomic_t> and C<int> are both exception-safe to	626	It assumes that C<sig_atomic_t>, C<int> and C<IV> are all async-safe to
195	modify (C<sig_atomic_> is used by this module, and perl itself uses	627	modify.
196	C<int>, so we can assume that this is quite portbale, at least w.r.t.
197	signals).
198		628
199	=head1 AUTHOR	629	=head1 AUTHOR
200		630
201	Marc Lehmann <schmorp@schmorp.de>	631	Marc Lehmann <schmorp@schmorp.de>
202	http://home.schmorp.de/	632	http://home.schmorp.de/

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing Async-Interrupt/Interrupt.pm (file contents): Revision 1.2 by root, Thu Jul 2 15:13:03 2009 UTC vs. Revision 1.29 by root, Tue Apr 24 20:52:35 2012 UTC

Diff Legend

Comparing Async-Interrupt/Interrupt.pm (file contents):
Revision 1.2 by root, Thu Jul 2 15:13:03 2009 UTC vs.
Revision 1.29 by root, Tue Apr 24 20:52:35 2012 UTC