… | |
… | |
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. |