diff options
| -rw-r--r-- | ev.pod | 8 |
1 files changed, 4 insertions, 4 deletions
@@ -3660,9 +3660,9 @@ already been invoked. A common way around all these issues is to make sure that C<start_new_request> I<always> returns before the callback is invoked. If C<start_new_request> immediately knows the result, it can artificially -delay invoking the callback by e.g. using a C<prepare> or C<idle> watcher -for example, or more sneakily, by reusing an existing (stopped) watcher -and pushing it into the pending queue: +delay invoking the callback by using a C<prepare> or C<idle> watcher for +example, or more sneakily, by reusing an existing (stopped) watcher and +pushing it into the pending queue: ev_set_cb (watcher, callback); ev_feed_event (EV_A_ watcher, 0); @@ -3680,7 +3680,7 @@ This brings the problem of exiting - a callback might want to finish the main C<ev_run> call, but not the nested one (e.g. user clicked "Quit", but a modal "Are you sure?" dialog is still waiting), or just the nested one and not the main one (e.g. user clocked "Ok" in a modal dialog), or some -other combination: In these cases, C<ev_break> will not work alone. +other combination: In these cases, a simple C<ev_break> will not work. The solution is to maintain "break this loop" variable for each C<ev_run> invocation, and use a loop around C<ev_run> until the condition is |