| … | |
… | |
| 103 | dies with a fatal error - obviously, you must never let this happen :). |
103 | dies with a fatal error - obviously, you must never let this happen :). |
| 104 | |
104 | |
| 105 | Eventually it returns the status value true if the command was successful, |
105 | Eventually it returns the status value true if the command was successful, |
| 106 | or the status value 0 and the stringified error message. |
106 | or the status value 0 and the stringified error message. |
| 107 | |
107 | |
| 108 | On my system, running the first cdoe fragment with the given |
108 | On my system, running the first code fragment with the given |
| 109 | F<MyWorker.pm> in the current directory yields: |
109 | F<MyWorker.pm> in the current directory yields: |
| 110 | |
110 | |
| 111 | /tmp/somepath/1: No such file or directory |
111 | /tmp/somepath/1: No such file or directory |
| 112 | /tmp/somepath/2: No such file or directory |
112 | /tmp/somepath/2: No such file or directory |
| 113 | 3 requests handled |
113 | 3 requests handled |
| … | |
… | |
| 198 | |
198 | |
| 199 | Called when the C<$rpc> object has been destroyed and all requests have |
199 | Called when the C<$rpc> object has been destroyed and all requests have |
| 200 | been successfully handled. This is useful when you queue some requests and |
200 | been successfully handled. This is useful when you queue some requests and |
| 201 | want the child to go away after it has handled them. The problem is that |
201 | want the child to go away after it has handled them. The problem is that |
| 202 | the parent must not exit either until all requests have been handled, and |
202 | the parent must not exit either until all requests have been handled, and |
| 203 | this cna be accomplished by waiting for this callback. |
203 | this can be accomplished by waiting for this callback. |
| 204 | |
204 | |
| 205 | =item init => $function (default none) |
205 | =item init => $function (default none) |
| 206 | |
206 | |
| 207 | When specified (by name), this function is called in the child as the very |
207 | When specified (by name), this function is called in the child as the very |
| 208 | first thing when taking over the process, with all the arguments normally |
208 | first thing when taking over the process, with all the arguments normally |
| … | |
… | |
| 231 | If you want to pre-load the actual back-end modules to enable memory |
231 | If you want to pre-load the actual back-end modules to enable memory |
| 232 | sharing, then you should load C<AnyEvent::Fork::RPC::Sync> for |
232 | sharing, then you should load C<AnyEvent::Fork::RPC::Sync> for |
| 233 | synchronous, and C<AnyEvent::Fork::RPC::Async> for asynchronous mode. |
233 | synchronous, and C<AnyEvent::Fork::RPC::Async> for asynchronous mode. |
| 234 | |
234 | |
| 235 | If you use a template process and want to fork both sync and async |
235 | If you use a template process and want to fork both sync and async |
| 236 | children, then it is permissible to laod both modules. |
236 | children, then it is permissible to load both modules. |
| 237 | |
237 | |
| 238 | =item serialiser => $string (default: '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })') |
238 | =item serialiser => $string (default: '(sub { pack "(w/a*)*", @_ }, sub { unpack "(w/a*)*", shift })') |
| 239 | |
239 | |
| 240 | All arguments, result data and event data have to be serialised to be |
240 | All arguments, result data and event data have to be serialised to be |
| 241 | transferred between the processes. For this, they have to be frozen and |
241 | transferred between the processes. For this, they have to be frozen and |
