[ViewVC] Diff of: cvs/libev/ev.pod

Comparing libev/ev.pod (file contents):
Revision 1.458 by root, Fri Dec 20 20:51:46 2019 UTC vs.
Revision 1.467 by root, Sun Sep 13 22:17:02 2020 UTC

    - Queue all expired timers.
    - Queue all expired periodics.
    - Queue all idle watchers with priority higher than that of pending events.
    - Queue all check watchers.
    - Call all queued watchers in reverse order (i.e. check watchers first).
-     Signals and child watchers are implemented as I/O watchers, and will
+     Signals, async and child watchers are implemented as I/O watchers, and
-     be handled here by queueing them when their watcher gets executed.
+     will be handled here by queueing them when their watcher gets executed.
    - If ev_break has been called, or EVRUN_ONCE or EVRUN_NOWAIT
      were used, or there are no active watchers, goto FINISH, otherwise
      continue with step LOOP.
    FINISH:
    - Reset the ev_break status iff it was EVBREAK_ONE.
 with a watcher-specific start function (C<< ev_TYPE_start (loop, watcher
 *) >>), and you can stop watching for events at any time by calling the
 corresponding stop function (C<< ev_TYPE_stop (loop, watcher *) >>.
 As long as your watcher is active (has been started but not stopped) you
-must not touch the values stored in it. Most specifically you must never
+must not touch the values stored in it except when explicitly documented
-reinitialise it or call its C<ev_TYPE_set> macro.
+otherwise. Most specifically you must never reinitialise it or call its
+C<ev_TYPE_set> macro.
 Each and every callback receives the event loop pointer as first, the
 registered watcher structure as second, and a bitset of received events as
 third argument.
 =item bool ev_is_active (ev_TYPE *watcher)
 Returns a true value iff the watcher is active (i.e. it has been started
 and not yet been stopped). As long as a watcher is active you must not modify
-it.
+it unless documented otherwise.
 =item bool ev_is_pending (ev_TYPE *watcher)
 Returns a true value iff the watcher is pending, (i.e. it has outstanding
 events but its callback has not yet been invoked). As long as a watcher
 This section describes each watcher in detail, but will not repeat
 information given in the last section. Any initialisation/set macros,
 functions and members specific to the watcher type are explained.
-Members are additionally marked with either I<[read-only]>, meaning that,
+Most members are additionally marked with either I<[read-only]>, meaning
-while the watcher is active, you can look at the member and expect some
+that, while the watcher is active, you can look at the member and expect
-sensible content, but you must not modify it (you can modify it while the
+some sensible content, but you must not modify it (you can modify it while
-watcher is stopped to your hearts content), or I<[read-write]>, which
+the watcher is stopped to your hearts content), or I<[read-write]>, which
-means you can expect it to have some sensible content while the watcher
+means you can expect it to have some sensible content while the watcher is
-is active, but you can also modify it. Modifying it may not do something
+active, but you can also modify it (within the same thread as the event
+loop, i.e. without creating data races). Modifying it may not do something
 sensible or take immediate effect (or do anything at all), but libev will
 not crash or malfunction in any way.
+In any case, the documentation for each member will explain what the
+effects are, and if there are any additional access restrictions.
 =head2 C<ev_io> - is this file descriptor readable or writable?
 I/O watchers check whether a file descriptor is readable or writable
 in each iteration of the event loop, or, more precisely, when reading
 =item ev_io_init (ev_io *, callback, int fd, int events)
 =item ev_io_set (ev_io *, int fd, int events)
 Configures an C<ev_io> watcher. The C<fd> is the file descriptor to
-receive events for and C<events> is either C<EV_READ>, C<EV_WRITE> or
+receive events for and C<events> is either C<EV_READ>, C<EV_WRITE>, both
-C<EV_READ | EV_WRITE>, to express the desire to receive the given events.
+C<EV_READ | EV_WRITE> or C<0>, to express the desire to receive the given
+events.
-=item int fd [read-only]
+Note that setting the C<events> to C<0> and starting the watcher is
+supported, but not specially optimized - if your program sometimes happens
+to generate this combination this is fine, but if it is easy to avoid
+starting an io watcher watching for no events you should do so.
-The file descriptor being watched.
+=item ev_io_modify (ev_io *, int events)
+Similar to C<ev_io_set>, but only changes the requested events. Using this
+might be faster with some backends, as libev can assume that the C<fd>
+still refers to the same underlying file description, something it cannot
+do when using C<ev_io_set>.
+=item int fd [no-modify]
+The file descriptor being watched. While it can be read at any time, you
+must not modify this member even when the watcher is stopped - always use
+C<ev_io_set> for that.
-=item int events [read-only]
+=item int events [no-modify]
-The events being watched.
+The set of events the fd is being watched for, among other flags. Remember
+that this is a bit set - to test for C<EV_READ>, use C<< w->events &
+EV_READ >>, and similarly for C<EV_WRITE>.
+As with C<fd>, you must not modify this member even when the watcher is
+stopped, always use C<ev_io_set> or C<ev_io_modify> for that.
 =back
 =head3 Examples
 event loop thread and an unspecified mechanism to wake up the main thread.
 First, you need to associate some data with the event loop:
    typedef struct {
-     mutex_t lock; /* global loop lock */
+     pthread_mutex_t lock; /* global loop lock */
+     pthread_t tid;
+     pthread_cond_t invoke_cv;
      ev_async async_w;
-     thread_t tid;
-     cond_t invoke_cv;
    } userdata;
    void prepare_loop (EV_P)
    {
       // for simplicity, we use a static userdata struct.
       static userdata u;
-      ev_async_init (&u->async_w, async_cb);
+      ev_async_init (&u.async_w, async_cb);
-      ev_async_start (EV_A_ &u->async_w);
+      ev_async_start (EV_A_ &u.async_w);
-      pthread_mutex_init (&u->lock, 0);
+      pthread_mutex_init (&u.lock, 0);
-      pthread_cond_init (&u->invoke_cv, 0);
+      pthread_cond_init (&u.invoke_cv, 0);
       // now associate this with the loop
-      ev_set_userdata (EV_A_ u);
+      ev_set_userdata (EV_A_ &u);
       ev_set_invoke_pending_cb (EV_A_ l_invoke);
       ev_set_loop_release_cb (EV_A_ l_release, l_acquire);
       // then create the thread running ev_run
-      pthread_create (&u->tid, 0, l_run, EV_A);
+      pthread_create (&u.tid, 0, l_run, EV_A);
    }
 The callback for the C<ev_async> watcher does nothing: the watcher is used
 solely to wake up the event loop so it takes notice of any new watchers
 that might have been added:
 gets automatically stopped and restarted when reconfiguring it with this
 method.
 For C<ev::embed> watchers this method is called C<set_embed>, to avoid
 clashing with the C<set (loop)> method.
+For C<ev::io> watchers there is an additional C<set> method that acepts a
+new event mask only, and internally calls C<ev_io_modfify>.
 =item w->start ()
 Starts the watcher. Note that there is no C<loop> argument, as the
 constructor already stores the event loop.

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing libev/ev.pod (file contents): Revision 1.458 by root, Fri Dec 20 20:51:46 2019 UTC vs. Revision 1.467 by root, Sun Sep 13 22:17:02 2020 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.458 by root, Fri Dec 20 20:51:46 2019 UTC vs.
Revision 1.467 by root, Sun Sep 13 22:17:02 2020 UTC