Lines Matching refs:ev_run
33 // this causes all nested ev_run's to stop iterating
42 // this causes the innermost ev_run to stop iterating
63 ev_run (loop, 0);
350 one calling C<ev_run> or otherwise qualifies as "the main program".
687 This function sets a flag that causes subsequent C<ev_run> iterations
692 C<EVFLAG_FORKCHECK>) in the child before resuming or calling C<ev_run>.
742 Returns the number of times C<ev_run> was entered minus the number of
743 times C<ev_run> was exited normally, in other words, the recursion depth.
745 Outside C<ev_run>, this number is zero. In a callback, this number is
746 C<1>, unless C<ev_run> was invoked recursively (or from another thread),
749 Leaving C<ev_run> abnormally (setjmp/longjmp, cancelling the thread,
771 is usually done automatically within C<ev_run ()>.
805 =item bool ev_run (loop, int flags)
819 (which usually means " you should call C<ev_run> again").
829 C<ev_run> call by calling C<longjmp> in a callback, throwing a C++
848 own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is
851 Here are the gory details of what C<ev_run> does (this is for your
895 ev_run (my_loop, 0);
900 Can be used to make a call to C<ev_run> return early (but only after it
902 C<EVBREAK_ONE>, which will make the innermost C<ev_run> call return, or
903 C<EVBREAK_ALL>, which will make all nested C<ev_run> calls return.
905 This "break state" will be cleared on the next call to C<ev_run>.
907 It is safe to call C<ev_break> from outside any C<ev_run> calls, too, in
916 count is nonzero, C<ev_run> will not return on its own.
919 unregister, but that nevertheless should not keep C<ev_run> from
924 is not visible to the libev user and should not keep C<ev_run> from
933 Example: Create a signal watcher, but keep it from keeping C<ev_run>
1007 pending state. Normally, C<ev_run> does this automatically when required,
1012 thread executes within C<ev_invoke_pending> or C<ev_run> of course).
1022 invoking all pending watchers when there are any, C<ev_run> will call
1035 However, C<ev_run> can run an indefinite time, so it is not feasible
1051 waited. Use an C<ev_async> watcher to wake up C<ev_run> when you want it
1054 In theory, threads executing C<ev_run> will be async-cancel safe between
1113 ev_run (loop, 0);
1187 All C<ev_prepare> watchers are invoked just I<before> C<ev_run> starts to
1189 just after C<ev_run> has gathered them, but before it queues any callbacks
1197 C<ev_prepare> watcher might start an idle watcher to keep C<ev_run> from
1777 ev_run (loop, 0);
1797 longer true when a callback calls C<ev_run> recursively).
2029 time only before and after C<ev_run> collects new events, which causes a
2200 ev_run (loop, 0);
2236 (but this is no longer true when a callback calls C<ev_run> recursively).
2918 You I<must not> call C<ev_run> (or similar functions that enter the
3116 ev_run (EV_A_ 0);
3204 similarly to C<ev_run (embedded_loop, EVRUN_NOWAIT)>, but in the most
3688 invoking C<ev_run>.
3691 main C<ev_run> call, but not the nested one (e.g. user clicked "Quit", but
3696 The solution is to maintain "break this loop" variable for each C<ev_run>
3697 invocation, and use a loop around C<ev_run> until the condition is
3704 ev_run (EV_DEFAULT_ EVRUN_ONCE);
3710 ev_run (EV_A_ EVRUN_ONCE);
3762 // then create the thread running ev_run
3794 into C<ev_run>:
3803 ev_run (EV_A_ 0);
3980 The only API functions that can currently throw exceptions are C<ev_run>,
4287 ev_run (EV_A_ 0);
4341 ev_run (EV_DEFAULT_ 0);
5032 coroutines (e.g. you can call C<ev_run> on the same loop from two
5038 C<ev_run>, and other calls do not usually allow for coroutine switches as
5456 ev_loop => ev_run