Browse Source

*** empty log message ***

master
Marc Alexander Lehmann 9 years ago
parent
commit
630069473e
  1. 8
      ev.pod

8
ev.pod

@ -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

Loading…
Cancel
Save