ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent-Fork-RPC/RPC.pm
Revision: 1.7
Committed: Wed Apr 17 20:19:41 2013 UTC (11 years, 3 months ago) by root
Branch: MAIN
Changes since 1.6: +6 -3 lines
Log Message:
*** empty log message ***

File Contents

# Content
1 =head1 NAME
2
3 AnyEvent::Fork::RPC - simple RPC extension for AnyEvent::Fork
4
5 =head1 SYNOPSIS
6
7 use AnyEvent::Fork::RPC;
8 # use AnyEvent::Fork is not needed
9
10 my $rpc = AnyEvent::Fork
11 ->new
12 ->require ("MyModule")
13 ->AnyEvent::Fork::RPC::run (
14 "MyModule::server",
15 );
16
17 my $cv = AE::cv;
18
19 $rpc->(1, 2, 3, sub {
20 print "MyModule::server returned @_\n";
21 $cv->send;
22 });
23
24 $cv->recv;
25
26 =head1 DESCRIPTION
27
28 This module implements a simple RPC protocol and backend for processes
29 created via L<AnyEvent::Fork>, allowing you to call a function in the
30 child process and receive its return values (up to 4GB serialised).
31
32 It implements two different backends: a synchronous one that works like a
33 normal function call, and an asynchronous one that can run multiple jobs
34 concurrently in the child, using AnyEvent.
35
36 It also implements an asynchronous event mechanism from the child to the
37 parent, that could be used for progress indications or other information.
38
39 Loading this module also always loads L<AnyEvent::Fork>, so you can make a
40 separate C<use AnyEvent::Fork> if you wish, but you don't have to.
41
42 =head1 EXAMPLES
43
44 =head2 Synchronous Backend
45
46 Here is a simple example that implements a backend that executes C<unlink>
47 and C<rmdir> calls, and reports their status back. It also reports the
48 number of requests it has processed every three requests, which is clearly
49 silly, but illustrates the use of events.
50
51 First the parent process:
52
53 use AnyEvent;
54 use AnyEvent::Fork;
55 use AnyEvent::Fork::RPC;
56
57 my $done = AE::cv;
58
59 my $rpc = AnyEvent::Fork
60 ->new
61 ->require ("MyWorker")
62 ->AnyEvent::Fork::RPC::run ("MyWorker::run",
63 on_error => sub { warn "FATAL: $_[0]"; exit 1 },
64 on_event => sub { warn "$_[0] requests handled\n" },
65 on_destroy => $done,
66 );
67
68 for my $id (1..6) {
69 $rpc->(rmdir => "/tmp/somepath/$id", sub {
70 $_[0]
71 or warn "/tmp/somepath/$id: $_[1]\n";
72 });
73 }
74
75 undef $rpc;
76
77 $done->recv;
78
79 The parent creates the process, queues a few rmdir's. It then forgets
80 about the C<$rpc> object, so that the child exits after it has handled the
81 requests, and then it waits till the requests have been handled.
82
83 The child is implemented using a separate module, C<MyWorker>, shown here:
84
85 package MyWorker;
86
87 my $count;
88
89 sub run {
90 my ($cmd, $path) = @_;
91
92 AnyEvent::Fork::RPC::event ($count)
93 unless ++$count % 3;
94
95 my $status = $cmd eq "rmdir" ? rmdir $path
96 : $cmd eq "unlink" ? unlink $path
97 : die "fatal error, illegal command '$cmd'";
98
99 $status or (0, "$!")
100 }
101
102 1
103
104 The C<run> function first sends a "progress" event every three calls, and
105 then executes C<rmdir> or C<unlink>, depending on the first parameter (or
106 dies with a fatal error - obviously, you must never let this happen :).
107
108 Eventually it returns the status value true if the command was successful,
109 or the status value 0 and the stringified error message.
110
111 On my system, running the first code fragment with the given
112 F<MyWorker.pm> in the current directory yields:
113
114 /tmp/somepath/1: No such file or directory
115 /tmp/somepath/2: No such file or directory
116 3 requests handled
117 /tmp/somepath/3: No such file or directory
118 /tmp/somepath/4: No such file or directory
119 /tmp/somepath/5: No such file or directory
120 6 requests handled
121 /tmp/somepath/6: No such file or directory
122
123 Obviously, none of the directories I am trying to delete even exist. Also,
124 the events and responses are processed in exactly the same order as
125 they were created in the child, which is true for both synchronous and
126 asynchronous backends.
127
128 Note that the parentheses in the call to C<AnyEvent::Fork::RPC::event> are
129 not optional. That is because the function isn't defined when the code is
130 compiled. You can make sure it is visible by pre-loading the correct
131 backend module in the call to C<require>:
132
133 ->require ("AnyEvent::Fork::RPC::Sync", "MyWorker")
134
135 Since the backend module declares the C<event> function, loading it first
136 ensures that perl will correctly interpret calls to it.
137
138 And as a final remark, there is a fine module on CPAN that can
139 asynchronously C<rmdir> and C<unlink> and a lot more, and more efficiently
140 than this example, namely L<IO::AIO>.
141
142 =head1 PARENT PROCESS USAGE
143
144 This module exports nothing, and only implements a single function:
145
146 =over 4
147
148 =cut
149
150 package AnyEvent::Fork::RPC;
151
152 use common::sense;
153
154 use Errno ();
155 use Guard ();
156
157 use AnyEvent;
158 use AnyEvent::Fork; # we don't actually depend on it, this is for convenience
159
160 our $VERSION = 0.1;
161
162 =item my $rpc = AnyEvent::Fork::RPC::run $fork, $function, [key => value...]
163
164 The traditional way to call it. But it is way cooler to call it in the
165 following way:
166
167 =item my $rpc = $fork->AnyEvent::Fork::RPC::run ($function, [key => value...])
168
169 This C<run> function/method can be used in place of the
170 L<AnyEvent::Fork::run> method. Just like that method, it takes over
171 the L<AnyEvent::Fork> process, but instead of calling the specified
172 C<$function> directly, it runs a server that accepts RPC calls and handles
173 responses.
174
175 It returns a function reference that can be used to call the function in
176 the child process, handling serialisation and data transfers.
177
178 The following key/value pairs are allowed. It is recommended to have at
179 least an C<on_error> or C<on_event> handler set.
180
181 =over 4
182
183 =item on_error => $cb->($msg)
184
185 Called on (fatal) errors, with a descriptive (hopefully) message. If
186 this callback is not provided, but C<on_event> is, then the C<on_event>
187 callback is called with the first argument being the string C<error>,
188 followed by the error message.
189
190 If neither handler is provided it prints the error to STDERR and will
191 start failing badly.
192
193 =item on_event => $cb->(...)
194
195 Called for every call to the C<AnyEvent::Fork::RPC::event> function in the
196 child, with the arguments of that function passed to the callback.
197
198 Also called on errors when no C<on_error> handler is provided.
199
200 =item on_destroy => $cb->()
201
202 Called when the C<$rpc> object has been destroyed and all requests have
203 been successfully handled. This is useful when you queue some requests and
204 want the child to go away after it has handled them. The problem is that
205 the parent must not exit either until all requests have been handled, and
206 this can be accomplished by waiting for this callback.
207
208 =item init => $function (default none)
209
210 When specified (by name), this function is called in the child as the very
211 first thing when taking over the process, with all the arguments normally
212 passed to the C<AnyEvent::Fork::run> function, except the communications
213 socket.
214
215 It can be used to do one-time things in the child such as storing passed
216 parameters or opening database connections.
217
218 It is called very early - before the serialisers are created or the
219 C<$function> name is resolved into a function reference, so it could be
220 used to load any modules that provide the serialiser or function. It can
221 not, however, create events.
222
223 =item async => $boolean (default: 0)
224
225 The default server used in the child does all I/O blockingly, and only
226 allows a single RPC call to execute concurrently.
227
228 Setting C<async> to a true value switches to another implementation that
229 uses L<AnyEvent> in the child and allows multiple concurrent RPC calls.
230
231 The actual API in the child is documented in the section that describes
232 the calling semantics of the returned C<$rpc> function.
233
234 If you want to pre-load the actual back-end modules to enable memory
235 sharing, then you should load C<AnyEvent::Fork::RPC::Sync> for
236 synchronous, and C<AnyEvent::Fork::RPC::Async> for asynchronous mode.
237
238 If you use a template process and want to fork both sync and async
239 children, then it is permissible to load both modules.
240
241 =item serialiser => $string (default: '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })')
242
243 All arguments, result data and event data have to be serialised to be
244 transferred between the processes. For this, they have to be frozen and
245 thawed in both parent and child processes.
246
247 By default, only octet strings can be passed between the processes, which
248 is reasonably fast and efficient.
249
250 For more complicated use cases, you can provide your own freeze and thaw
251 functions, by specifying a string with perl source code. It's supposed to
252 return two code references when evaluated: the first receives a list of
253 perl values and must return an octet string. The second receives the octet
254 string and must return the original list of values.
255
256 If you need an external module for serialisation, then you can either
257 pre-load it into your L<AnyEvent::Fork> process, or you can add a C<use>
258 or C<require> statement into the serialiser string. Or both.
259
260 =back
261
262 =cut
263
264 our $STRING_SERIALISER = '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })';
265
266 sub run {
267 my ($self, $function, %arg) = @_;
268
269 my $serialiser = delete $arg{serialiser} || $STRING_SERIALISER;
270 my $on_event = delete $arg{on_event};
271 my $on_error = delete $arg{on_error};
272 my $on_destroy = delete $arg{on_destroy};
273
274 # default for on_error is to on_event, if specified
275 $on_error ||= $on_event
276 ? sub { $on_event->(error => shift) }
277 : sub { die "AnyEvent::Fork::RPC: uncaught error: $_[0].\n" };
278
279 # default for on_event is to raise an error
280 $on_event ||= sub { $on_error->("event received, but no on_event handler") };
281
282 my ($f, $t) = eval $serialiser; die $@ if $@;
283
284 my (@rcb, $fh, $shutdown, $wbuf, $ww, $rw);
285 my ($rlen, $rbuf) = 512 - 16;
286
287 my $wcb = sub {
288 my $len = syswrite $fh, $wbuf;
289
290 if (!defined $len) {
291 if ($! != Errno::EAGAIN && $! != Errno::EWOULDBLOCK) {
292 undef $rw; undef $ww; # it ends here
293 $on_error->("$!");
294 }
295 }
296
297 substr $wbuf, 0, $len, "";
298
299 unless (length $wbuf) {
300 undef $ww;
301 $shutdown and shutdown $fh, 1;
302 }
303 };
304
305 my $module = "AnyEvent::Fork::RPC::" . ($arg{async} ? "Async" : "Sync");
306
307 $self->require ($module)
308 ->send_arg ($function, $arg{init}, $serialiser)
309 ->run ("$module\::run", sub {
310 $fh = shift;
311 $rw = AE::io $fh, 0, sub {
312 $rlen = $rlen * 2 + 16 if $rlen - 128 < length $rbuf;
313 my $len = sysread $fh, $rbuf, $rlen - length $rbuf, length $rbuf;
314
315 if ($len) {
316 while (4 <= length $rbuf) {
317 $len = unpack "L", $rbuf;
318 4 + $len <= length $rbuf
319 or last;
320
321 my @r = $t->(substr $rbuf, 4, $len);
322 substr $rbuf, 0, $len + 4, "";
323
324 if (pop @r) {
325 $on_event->(@r);
326 } elsif (@rcb) {
327 (shift @rcb)->(@r);
328 } else {
329 undef $rw; undef $ww;
330 $on_error->("unexpected data from child");
331 }
332 }
333 } elsif (defined $len) {
334 undef $rw; undef $ww; # it ends here
335
336 if (@rcb) {
337 $on_error->("unexpected eof");
338 } else {
339 $on_destroy->();
340 }
341 } elsif ($! != Errno::EAGAIN && $! != Errno::EWOULDBLOCK) {
342 undef $rw; undef $ww; # it ends here
343 $on_error->("read: $!");
344 }
345 };
346
347 $ww ||= AE::io $fh, 1, $wcb;
348 });
349
350 my $guard = Guard::guard {
351 $shutdown = 1;
352 $ww ||= $fh && AE::io $fh, 1, $wcb;
353 };
354
355 sub {
356 push @rcb, pop;
357
358 $guard; # keep it alive
359
360 $wbuf .= pack "L/a*", &$f;
361 $ww ||= $fh && AE::io $fh, 1, $wcb;
362 }
363 }
364
365 =item $rpc->(..., $cb->(...))
366
367 The RPC object returned by C<AnyEvent::Fork::RPC::run> is actually a code
368 reference. There are two things you can do with it: call it, and let it go
369 out of scope (let it get destroyed).
370
371 If C<async> was false when C<$rpc> was created (the default), then, if you
372 call C<$rpc>, the C<$function> is invoked with all arguments passed to
373 C<$rpc> except the last one (the callback). When the function returns, the
374 callback will be invoked with all the return values.
375
376 If C<async> was true, then the C<$function> receives an additional
377 initial argument, the result callback. In this case, returning from
378 C<$function> does nothing - the function only counts as "done" when the
379 result callback is called, and any arguments passed to it are considered
380 the return values. This makes it possible to "return" from event handlers
381 or e.g. Coro threads.
382
383 The other thing that can be done with the RPC object is to destroy it. In
384 this case, the child process will execute all remaining RPC calls, report
385 their results, and then exit.
386
387 =back
388
389 =head1 CHILD PROCESS USAGE
390
391 The following function is not available in this module. They are only
392 available in the namespace of this module when the child is running,
393 without having to load any extra modules. They are part of the child-side
394 API of L<AnyEvent::Fork::RPC>.
395
396 =over 4
397
398 =item AnyEvent::Fork::RPC::event ...
399
400 Send an event to the parent. Events are a bit like RPC calls made by the
401 child process to the parent, except that there is no notion of return
402 values.
403
404 =back
405
406 =head1 SEE ALSO
407
408 L<AnyEvent::Fork> (to create the processes in the first place),
409 L<AnyEvent::Fork::Pool> (to manage whole pools of processes).
410
411 =head1 AUTHOR AND CONTACT INFORMATION
412
413 Marc Lehmann <schmorp@schmorp.de>
414 http://software.schmorp.de/pkg/AnyEvent-Fork-RPC
415
416 =cut
417
418 1
419