| … | |
… | |
| 39 | Loading this module also always loads L<AnyEvent::Fork>, so you can make a |
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. |
40 | separate C<use AnyEvent::Fork> if you wish, but you don't have to. |
| 41 | |
41 | |
| 42 | =head1 EXAMPLES |
42 | =head1 EXAMPLES |
| 43 | |
43 | |
| 44 | =head2 Synchronous Backend |
44 | =head2 Example 1: Synchronous Backend |
| 45 | |
45 | |
| 46 | Here is a simple example that implements a backend that executes C<unlink> |
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 |
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 |
48 | number of requests it has processed every three requests, which is clearly |
| 49 | silly, but illustrates the use of events. |
49 | silly, but illustrates the use of events. |
| … | |
… | |
| 136 | ensures that perl will correctly interpret calls to it. |
136 | ensures that perl will correctly interpret calls to it. |
| 137 | |
137 | |
| 138 | And as a final remark, there is a fine module on CPAN that can |
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 |
139 | asynchronously C<rmdir> and C<unlink> and a lot more, and more efficiently |
| 140 | than this example, namely L<IO::AIO>. |
140 | than this example, namely L<IO::AIO>. |
|
|
141 | |
|
|
142 | =head3 Example 1a: the same with the asynchronous backend |
|
|
143 | |
|
|
144 | This example only shows what needs to be changed to use the async backend |
|
|
145 | instead. Doing this is not very useful, the purpose of this example is |
|
|
146 | to show the minimum amount of change that is required to go from the |
|
|
147 | synchronous to the asynchronous backend. |
|
|
148 | |
|
|
149 | To use the async backend in the previous example, you need to add the |
|
|
150 | C<async> parameter to the C<AnyEvent::Fork::RPC::run> call: |
|
|
151 | |
|
|
152 | ->AnyEvent::Fork::RPC::run ("MyWorker::run", |
|
|
153 | async => 1, |
|
|
154 | ... |
|
|
155 | |
|
|
156 | And since the function call protocol is now changed, you need to adopt |
|
|
157 | C<MyWorker::run> to the async API. |
|
|
158 | |
|
|
159 | First, you need to accept the extra initial C<$done> callback: |
|
|
160 | |
|
|
161 | sub run { |
|
|
162 | my ($done, $cmd, $path) = @_; |
|
|
163 | |
|
|
164 | And since a response is now generated when C<$done> is called, as opposed |
|
|
165 | to when the function returns, we need to call the C<$done> function with |
|
|
166 | the status: |
|
|
167 | |
|
|
168 | $done->($status or (0, "$!")); |
|
|
169 | |
|
|
170 | A few remarks are in order. First, it's quite pointless to use the async |
|
|
171 | backend for this example - but it I<is> possible. Second, you can call |
|
|
172 | C<$done> before or after returning from the function. Third, having both |
|
|
173 | returned from the function and having called the C<$done> callback, the |
|
|
174 | child process may exit at any time, so you should call C<$done> only when |
|
|
175 | you really I<are> done. |
|
|
176 | |
|
|
177 | =head2 Example 2: Asynchronous Backend |
|
|
178 | |
|
|
179 | #TODO |
| 141 | |
180 | |
| 142 | =head1 PARENT PROCESS USAGE |
181 | =head1 PARENT PROCESS USAGE |
| 143 | |
182 | |
| 144 | This module exports nothing, and only implements a single function: |
183 | This module exports nothing, and only implements a single function: |
| 145 | |
184 | |
