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

Comparing libev/ev.pod (file contents):
Revision 1.296 by root, Tue Jun 29 10:51:18 2010 UTC vs.
Revision 1.298 by sf-exg, Sat Jul 31 23:00:11 2010 UTC

 While this document tries to be as complete as possible in documenting
 libev, its usage and the rationale behind its design, it is not a tutorial
 on event-based programming, nor will it introduce event-based programming
 with libev.
-Familarity with event based programming techniques in general is assumed
+Familiarity with event based programming techniques in general is assumed
 throughout this document.
 =head1 ABOUT LIBEV
 Libev is an event loop: you register interest in certain events (such as a
 C<ev_resume> directly afterwards to resume timer processing.
 Effectively, all C<ev_timer> watchers will be delayed by the time spend
 between C<ev_suspend> and C<ev_resume>, and all C<ev_periodic> watchers
 will be rescheduled (that is, they will lose any events that would have
-occured while suspended).
+occurred while suspended).
 After calling C<ev_suspend> you B<must not> call I<any> function on the
 given loop other than C<ev_resume>, and you B<must not> call C<ev_resume>
 without a previous call to C<ev_suspend>.
 C<EVUNLOOP_ONE>, which will make the innermost C<ev_loop> call return, or
 C<EVUNLOOP_ALL>, which will make all nested C<ev_loop> calls return.
 This "unloop state" will be cleared when entering C<ev_loop> again.
-It is safe to call C<ev_unloop> from otuside any C<ev_loop> calls.
+It is safe to call C<ev_unloop> from outside any C<ev_loop> calls.
 =item ev_ref (loop)
 =item ev_unref (loop)
 usually doesn't make much sense to set it to a lower value than C<0.01>,
 as this approaches the timing granularity of most systems. Note that if
 you do transactions with the outside world and you can't increase the
 parallelity, then this setting will limit your transaction rate (if you
 need to poll once per transaction and the I/O collect interval is 0.01,
-then you can't do more than 100 transations per second).
+then you can't do more than 100 transactions per second).
 Setting the I<timeout collect interval> can improve the opportunity for
 saving power, as the program will "bundle" timer callback invocations that
 are "near" in time together, by delaying some, thus reducing the number of
 times the process sleeps and wakes up again. Another useful technique to
 For example, to emulate how many other event libraries handle priorities,
 you can associate an C<ev_idle> watcher to each such watcher, and in
 the normal watcher callback, you just start the idle watcher. The real
 processing is done in the idle watcher callback. This causes libev to
-continously poll and process kernel event data for the watcher, but when
+continuously poll and process kernel event data for the watcher, but when
 the lock-out case is known to be rare (which in turn is rare :), this is
 workable.
 Usually, however, the lock-out model implemented that way will perform
 miserably under the type of load it was designed to handle. In that case,
 If you cannot use non-blocking mode, then force the use of a
 known-to-be-good backend (at the time of this writing, this includes only
 C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). The same applies to file
 descriptors for which non-blocking operation makes no sense (such as
-files) - libev doesn't guarentee any specific behaviour in that case.
+files) - libev doesn't guarantee any specific behaviour in that case.
 Another thing you have to watch out for is that it is quite easy to
 receive "spurious" readiness notifications, that is your callback might
 be called with C<EV_READ> but a subsequent C<read>(2) will actually block
 because there is no data. Not only are some backends known to create a
      ev_tstamp timeout = last_activity + 60.;
      // if last_activity + 60. is older than now, we did time out
      if (timeout < now)
        {
-         // timeout occured, take action
+         // timeout occurred, take action
        }
      else
        {
          // callback was invoked, but there was some activity, re-arm
          // the watcher to fire in last_activity + 60, which is
    ev::io iow;
    iow.set <myclass, &myclass::io_cb> (&obj);
 =item w->set (object *)
-This is an B<experimental> feature that might go away in a future version.
 This is a variation of a method callback - leaving out the method to call
 will default the method to C<operator ()>, which makes it possible to use
 functor objects without having to manually specify the C<operator ()> all
 the time. Incidentally, you can then also leave out the template argument
 list.
 The highest supported signal number, +1 (or, the number of
 signals): Normally, libev tries to deduce the maximum number of signals
 automatically, but sometimes this fails, in which case it can be
 specified. Also, using a lower number than detected (C<32> should be
-good for about any system in existance) can save some memory, as libev
+good for about any system in existence) can save some memory, as libev
 statically allocates some 12-24 bytes per signal number.
 =item EV_PID_HASHSIZE
 C<ev_child> watchers use a small hash table to distribute workload by
 This is a simple rename - all other watcher types use their name
 as revents flag, and now C<ev_timer> does, too.
 Both C<EV_TIMER> and C<EV_TIMEOUT> symbols were present in 3.x versions
-and continue to be present for the forseeable future, so this is mostly a
+and continue to be present for the foreseeable future, so this is mostly a
 documentation change.
 =item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES>
 The preprocessor symbol C<EV_MINIMAL> has been replaced by a different

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.296 by root, Tue Jun 29 10:51:18 2010 UTC vs. Revision 1.298 by sf-exg, Sat Jul 31 23:00:11 2010 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.296 by root, Tue Jun 29 10:51:18 2010 UTC vs.
Revision 1.298 by sf-exg, Sat Jul 31 23:00:11 2010 UTC