| … | |
… | |
| 233 | watchers with higher priority will be invoked first. The valid range of |
233 | watchers with higher priority will be invoked first. The valid range of |
| 234 | priorities lies between EV::MAXPRI (default 2) and EV::MINPRI (default |
234 | priorities lies between EV::MAXPRI (default 2) and EV::MINPRI (default |
| 235 | -2). If the priority is outside this range it will automatically be |
235 | -2). If the priority is outside this range it will automatically be |
| 236 | normalised to the nearest valid priority. |
236 | normalised to the nearest valid priority. |
| 237 | |
237 | |
| 238 | The default priority of any newly-created weatcher is 0. |
238 | The default priority of any newly-created watcher is 0. |
|
|
239 | |
|
|
240 | Note that the priority semantics have not yet been fleshed out and are |
|
|
241 | subject to almost certain change. |
| 239 | |
242 | |
| 240 | =item $w->trigger ($revents) |
243 | =item $w->trigger ($revents) |
| 241 | |
244 | |
| 242 | Call the callback *now* with the given event mask. |
245 | Call the callback *now* with the given event mask. |
| 243 | |
246 | |
|
|
247 | =item $previous_state = $w->keepalive ($bool) |
|
|
248 | |
|
|
249 | Normally, C<EV::loop> will return when there are no active watchers |
|
|
250 | (which is a "deadlock" because no progress can be made anymore). This is |
|
|
251 | convinient because it allows you to start your watchers (and your jobs), |
|
|
252 | call C<EV::loop> once and when it returns you know that all your jobs are |
|
|
253 | finished (or they forgot to register some watchers for their task :). |
|
|
254 | |
|
|
255 | Sometimes, however, this gets in your way, for example when you the module |
|
|
256 | that calls C<EV::loop> (usually the main program) is not the same module |
|
|
257 | as a long-living watcher (for example a DNS client module written by |
|
|
258 | somebody else even). Then you might want any outstanding requests to be |
|
|
259 | handled, but you would not want to keep C<EV::loop> from returning just |
|
|
260 | because you happen to have this long-running UDP port watcher. |
|
|
261 | |
|
|
262 | In this case you can clear the keepalive status, which means that even |
|
|
263 | though your watcher is active, it won't keep C<EV::loop> from returning. |
|
|
264 | |
|
|
265 | The initial value for keepalive is true (enabled), and you cna change it |
|
|
266 | any time. |
|
|
267 | |
|
|
268 | Example: Register an IO watcher for some UDP socket but do not keep the |
|
|
269 | event loop from running just because of that watcher. |
|
|
270 | |
|
|
271 | my $udp_socket = ... |
|
|
272 | my $udp_watcher = EV::io $udp_socket, EV::READ, sub { ... }; |
|
|
273 | $udp_watcher->keepalive (0); |
| 244 | |
274 | |
| 245 | =item $w = EV::io $fileno_or_fh, $eventmask, $callback |
275 | =item $w = EV::io $fileno_or_fh, $eventmask, $callback |
| 246 | |
276 | |
| 247 | =item $w = EV::io_ns $fileno_or_fh, $eventmask, $callback |
277 | =item $w = EV::io_ns $fileno_or_fh, $eventmask, $callback |
| 248 | |
278 | |
