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

Comparing libev/ev.pod (file contents):
Revision 1.81 by root, Wed Dec 12 04:53:58 2007 UTC vs.
Revision 1.87 by root, Tue Dec 18 01:37:46 2007 UTC

 Libev represents time as a single floating point number, representing the
 (fractional) number of seconds since the (POSIX) epoch (somewhere near
 the beginning of 1970, details are complicated, don't ask). This type is
 called C<ev_tstamp>, which is what you should use too. It usually aliases
 to the C<double> type in C, and when you need to do any calculations on
-it, you should treat it as such.
+it, you should treat it as some floatingpoint value. Unlike the name
+component C<stamp> might indicate, it is also used for time differences
+throughout libev.
 =head1 GLOBAL FUNCTIONS
 These functions can be called anytime, even before initialising the
 library in any way.
 Destroys the default loop again (frees all memory and kernel state
 etc.). None of the active event watchers will be stopped in the normal
 sense, so e.g. C<ev_is_active> might still return true. It is your
 responsibility to either stop all watchers cleanly yoursef I<before>
 calling this function, or cope with the fact afterwards (which is usually
-the easiest thing, youc na just ignore the watchers and/or C<free ()> them
+the easiest thing, you can just ignore the watchers and/or C<free ()> them
 for example).
+Not that certain global state, such as signal state, will not be freed by
+this function, and related watchers (such as signal and child watchers)
+would need to be stopped manually.
+In general it is not advisable to call this function except in the
+rare occasion where you really need to free e.g. the signal handling
+pipe fds. If you need dynamically allocated loops it is better to use
+C<ev_loop_new> and C<ev_loop_destroy>).
 =item ev_loop_destroy (loop)
 Like C<ev_default_destroy>, but destroys an event loop created by an
 earlier call to C<ev_loop_new>.
 This is how one would do it normally anyway, the important point is that
 the libev application should not optimise around libev but should leave
 optimisations to libev.
+=head3 Watcher-Specific Functions
 =over 4
 =item ev_io_init (ev_io *, callback, int fd, int events)
 =item ev_io_set (ev_io *, int fd, int events)
    ev_timer_set (&timer, after + ev_now () - ev_time (), 0.);
 The callback is guarenteed to be invoked only when its timeout has passed,
 but if multiple timers become ready during the same loop iteration then
 order of execution is undefined.
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
 As with timers, the callback is guarenteed to be invoked only when the
 time (C<at>) has been passed, but if multiple periodic timers become ready
 during the same loop iteration then order of execution is undefined.
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)
 =item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)
 =item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write]
 The current reschedule callback, or C<0>, if this functionality is
 switched off. Can be changed any time, but changes only take effect when
 the periodic timer fires or C<ev_periodic_again> is being called.
+=item ev_tstamp at [read-only]
+When active, contains the absolute time that the watcher is supposed to
+trigger next.
 =back
 Example: Call a callback every hour, or, more precisely, whenever the
 system clock is divisible by 3600. The callback invocation times have
 with the kernel (thus it coexists with your own signal handlers as long
 as you don't register any with libev). Similarly, when the last signal
 watcher for a signal is stopped libev will reset the signal handler to
 SIG_DFL (regardless of what it was set to before).
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_signal_init (ev_signal *, callback, int signum)
 =item ev_signal_set (ev_signal *, int signum)
 =head2 C<ev_child> - watch out for process status changes
 Child watchers trigger when your process receives a SIGCHLD in response to
 some child status changes (most typically when a child of yours dies).
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_child_init (ev_child *, callback, int pid)
 reader). Inotify will be used to give hints only and should not change the
 semantics of C<ev_stat> watchers, which means that libev sometimes needs
 to fall back to regular polling again even with inotify, but changes are
 usually detected immediately, and if the file exists there will be no
 polling.
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)
 Apart from keeping your process non-blocking (which is a useful
 effect on its own sometimes), idle watchers are a good place to do
 "pseudo-background processing", or delay processing stuff to after the
 event loop has handled all outstanding events.
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_idle_init (ev_signal *, callback)
 Initialises and configures the idle watcher - it has no parameters of any
 their job. As C<ev_check> watchers are often used to embed other event
 loops those other event loops might be in an unusable state until their
 C<ev_check> watcher ran (always remind yourself to coexist peacefully with
 others).
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_prepare_init (ev_prepare *, callback)
 =item ev_check_init (ev_check *, callback)
       ev_embed_start (loop_hi, &embed);
     }
   else
     loop_lo = loop_hi;
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)
 =item ev_embed_set (ev_embed *, callback, struct ev_loop *embedded_loop)
 event loop blocks next and before C<ev_check> watchers are being called,
 and only in the child after the fork. If whoever good citizen calling
 C<ev_default_fork> cheats and calls it in the wrong process, the fork
 handlers will be invoked, too, of course.
+=head3 Watcher-Specific Functions and Data Members
 =over 4
 =item ev_fork_init (ev_signal *, callback)
 Initialises and configures the fork watcher - it has no parameters of any
 =item w->stop ()
 Stops the watcher if it is active. Again, no C<loop> argument.
-=item w->again ()       C<ev::timer>, C<ev::periodic> only
+=item w->again () (C<ev::timer>, C<ev::periodic> only)
 For C<ev::timer> and C<ev::periodic>, this invokes the corresponding
 C<ev_TYPE_again> function.
-=item w->sweep ()       C<ev::embed> only
+=item w->sweep () (C<ev::embed> only)
 Invokes C<ev_embed_sweep>.
-=item w->update ()      C<ev::stat> only
+=item w->update () (C<ev::stat> only)
 Invokes C<ev_stat_stat>.
 =back
   }
 =head1 MACRO MAGIC
-Libev can be compiled with a variety of options, the most fundemantal is
+Libev can be compiled with a variety of options, the most fundamantal
-C<EV_MULTIPLICITY>. This option determines whether (most) functions and
+of which is C<EV_MULTIPLICITY>. This option determines whether (most)
-callbacks have an initial C<struct ev_loop *> argument.
+functions and callbacks have an initial C<struct ev_loop *> argument.
 To make it easier to write programs that cope with either variant, the
 following macros are defined:
 =over 4

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.81 by root, Wed Dec 12 04:53:58 2007 UTC vs. Revision 1.87 by root, Tue Dec 18 01:37:46 2007 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.81 by root, Wed Dec 12 04:53:58 2007 UTC vs.
Revision 1.87 by root, Tue Dec 18 01:37:46 2007 UTC