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