| … | |
… | |
| 208 | If timeout is C<undef> or negative, then there will be no |
208 | If timeout is C<undef> or negative, then there will be no |
| 209 | timeout. Otherwise a EV::timer with this value will be started. |
209 | timeout. Otherwise a EV::timer with this value will be started. |
| 210 | |
210 | |
| 211 | When an error occurs or either the timeout or I/O watcher triggers, then |
211 | When an error occurs or either the timeout or I/O watcher triggers, then |
| 212 | the callback will be called with the received event set (in general |
212 | the callback will be called with the received event set (in general |
| 213 | you can expect it to be a combination of C<EV:ERROR>, C<EV::READ>, |
213 | you can expect it to be a combination of C<EV::ERROR>, C<EV::READ>, |
| 214 | C<EV::WRITE> and C<EV::TIMEOUT>). |
214 | C<EV::WRITE> and C<EV::TIMEOUT>). |
| 215 | |
215 | |
| 216 | EV::once doesn't return anything: the watchers stay active till either |
216 | EV::once doesn't return anything: the watchers stay active till either |
| 217 | of them triggers, then they will be stopped and freed, and the callback |
217 | of them triggers, then they will be stopped and freed, and the callback |
| 218 | invoked. |
218 | invoked. |
| … | |
… | |
| 239 | event. For instance, if you want to wait for STDIN to become readable, you |
239 | event. For instance, if you want to wait for STDIN to become readable, you |
| 240 | would create an EV::io watcher for that: |
240 | would create an EV::io watcher for that: |
| 241 | |
241 | |
| 242 | my $watcher = EV::io *STDIN, EV::READ, sub { |
242 | my $watcher = EV::io *STDIN, EV::READ, sub { |
| 243 | my ($watcher, $revents) = @_; |
243 | my ($watcher, $revents) = @_; |
| 244 | warn "yeah, STDIN should not be readable without blocking!\n" |
244 | warn "yeah, STDIN should now be readable without blocking!\n" |
| 245 | }; |
245 | }; |
| 246 | |
246 | |
| 247 | All watchers can be active (waiting for events) or inactive (paused). Only |
247 | All watchers can be active (waiting for events) or inactive (paused). Only |
| 248 | active watchers will have their callbacks invoked. All callbacks will be |
248 | active watchers will have their callbacks invoked. All callbacks will be |
| 249 | called with at least two arguments: the watcher and a bitmask of received |
249 | called with at least two arguments: the watcher and a bitmask of received |
| … | |
… | |
| 345 | (which is a "deadlock" because no progress can be made anymore). This is |
345 | (which is a "deadlock" because no progress can be made anymore). This is |
| 346 | convinient because it allows you to start your watchers (and your jobs), |
346 | convinient because it allows you to start your watchers (and your jobs), |
| 347 | call C<EV::loop> once and when it returns you know that all your jobs are |
347 | call C<EV::loop> once and when it returns you know that all your jobs are |
| 348 | finished (or they forgot to register some watchers for their task :). |
348 | finished (or they forgot to register some watchers for their task :). |
| 349 | |
349 | |
| 350 | Sometimes, however, this gets in your way, for example when you the module |
350 | Sometimes, however, this gets in your way, for example when the module |
| 351 | that calls C<EV::loop> (usually the main program) is not the same module |
351 | that calls C<EV::loop> (usually the main program) is not the same module |
| 352 | as a long-living watcher (for example a DNS client module written by |
352 | as a long-living watcher (for example a DNS client module written by |
| 353 | somebody else even). Then you might want any outstanding requests to be |
353 | somebody else even). Then you might want any outstanding requests to be |
| 354 | handled, but you would not want to keep C<EV::loop> from returning just |
354 | handled, but you would not want to keep C<EV::loop> from returning just |
| 355 | because you happen to have this long-running UDP port watcher. |
355 | because you happen to have this long-running UDP port watcher. |
