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

Comparing libev/ev.pod (file contents):
Revision 1.399 by root, Mon Apr 2 23:14:41 2012 UTC vs.
Revision 1.405 by root, Thu May 3 15:07:15 2012 UTC

 the current system, you would need to look at C<ev_embeddable_backends ()
 & ev_supported_backends ()>, likewise for recommended ones.
 See the description of C<ev_embed> watchers for more info.
-=item ev_set_allocator (void *(*cb)(void *ptr, long size))
+=item ev_set_allocator (void *(*cb)(void *ptr, long size) throw ())
 Sets the allocation function to use (the prototype is similar - the
 semantics are identical to the C<realloc> C89/SuS/POSIX function). It is
 used to allocate and free memory (no surprises here). If it returns zero
 when memory needs to be allocated (C<size != 0>), the library might abort
    }
    ...
    ev_set_allocator (persistent_realloc);
-=item ev_set_syserr_cb (void (*cb)(const char *msg))
+=item ev_set_syserr_cb (void (*cb)(const char *msg) throw ())
 Set the callback function to call on a retryable system call error (such
 as failed select, poll, epoll_wait). The message is a printable string
 indicating the system call or subsystem causing the problem. If this
 callback is set, then libev will expect it to remedy the situation, no
 invoke the actual watchers inside another context (another thread etc.).
 If you want to reset the callback, use C<ev_invoke_pending> as new
 callback.
-=item ev_set_loop_release_cb (loop, void (*release)(EV_P), void (*acquire)(EV_P))
+=item ev_set_loop_release_cb (loop, void (*release)(EV_P) throw (), void (*acquire)(EV_P) throw ())
 Sometimes you want to share the same loop between multiple threads. This
 can be done relatively simply by putting mutex_lock/unlock calls around
 each call to a libev function.
 =item C<EV_PREPARE>
 =item C<EV_CHECK>
-All C<ev_prepare> watchers are invoked just I<before> C<ev_run> starts
+All C<ev_prepare> watchers are invoked just I<before> C<ev_run> starts to
-to gather new events, and all C<ev_check> watchers are invoked just after
+gather new events, and all C<ev_check> watchers are queued (not invoked)
-C<ev_run> has gathered them, but before it invokes any callbacks for any
+just after C<ev_run> has gathered them, but before it queues any callbacks
+for any received events. That means C<ev_prepare> watchers are the last
+watchers invoked before the event loop sleeps or polls for new events, and
+C<ev_check> watchers will be invoked before any other watchers of the same
+or lower priority within an event loop iteration.
-received events. Callbacks of both watcher types can start and stop as
+Callbacks of both watcher types can start and stop as many watchers as
-many watchers as they want, and all of them will be taken into account
+they want, and all of them will be taken into account (for example, a
-(for example, a C<ev_prepare> watcher might start an idle watcher to keep
+C<ev_prepare> watcher might start an idle watcher to keep C<ev_run> from
-C<ev_run> from blocking).
+blocking).
 =item C<EV_EMBED>
 The embedded event loop specified in the C<ev_embed> watcher needs attention.
    callback (EV_P_ ev_timer *w, int revents)
    {
      // calculate when the timeout would happen
      ev_tstamp after = last_activity - ev_now (EV_A) + timeout;
-     // if negative, it means we the timeout already occured
+     // if negative, it means we the timeout already occurred
      if (after < 0.)
        {
          // timeout occurred, take action
        }
      else
 Otherwise, we now the earliest time at which the timeout would trigger,
 and simply start the timer with this timeout value.
 In other words, each time the callback is invoked it will check whether
-the timeout cocured. If not, it will simply reschedule itself to check
+the timeout occurred. If not, it will simply reschedule itself to check
 again at the earliest time it could time out. Rinse. Repeat.
 This scheme causes more callback invocations (about one every 60 seconds
 minus half the average time between activity), but virtually no calls to
 libev to change the timeout.
    if (activity detected)
      last_activity = ev_now (EV_A);
 When your timeout value changes, then the timeout can be changed by simply
 providing a new value, stopping the timer and calling the callback, which
-will agaion do the right thing (for example, time out immediately :).
+will again do the right thing (for example, time out immediately :).
    timeout = new_value;
    ev_timer_stop (EV_A_ &timer);
    callback (EV_A_ &timer, 0);
 it by calling C<ev_async_send>, which is thread- and signal safe.
 This functionality is very similar to C<ev_signal> watchers, as signals,
 too, are asynchronous in nature, and signals, too, will be compressed
 (i.e. the number of callback invocations may be less than the number of
-C<ev_async_sent> calls). In fact, you could use signal watchers as a kind
+C<ev_async_send> calls). In fact, you could use signal watchers as a kind
 of "global async watchers" by using a watcher on an otherwise unused
 signal, and C<ev_feed_signal> to signal this watcher from another thread,
 even without knowing which loop owns the signal.
 =head3 Queueing
 to use the libev header file and library.
 =back
 =head1 C++ SUPPORT
+=head2 C API
+The normal C API should work fine when used from C++: both ev.h and the
+libev sources can be compiled as C++. Therefore, code that uses the C API
+will work fine.
+Proper exception specifications might have to be added to callbacks passed
+to libev: exceptions may be thrown only from watcher callbacks, all
+other callbacks (allocator, syserr, loop acquire/release and periodioc
+reschedule callbacks) must not throw exceptions, and might need a C<throw
+()> specification. If you have code that needs to be compiled as both C
+and C++ you can use the C<EV_THROW> macro for this:
+   static void
+   fatal_error (const char *msg) EV_THROW
+   {
+     perror (msg);
+     abort ();
+   }
+   ...
+   ev_set_syserr_cb (fatal_error);
+The only API functions that can currently throw exceptions are C<ev_run>,
+C<ev_invoke>, C<ev_invoke_pending> and C<ev_loop_destroy> (the latter
+because it runs cleanup watchers).
+Throwing exceptions in watcher callbacks is only supported if libev itself
+is compiled with a C++ compiler or your C and C++ environments allow
+throwing exceptions through C libraries (most do).
+=head2 C++ API
 Libev comes with some simplistic wrapper classes for C++ that mainly allow
 you to use some convenience methods to start/stop watchers and also change
 the callback model to a model using method callbacks on objects.
    #define EV_USE_POLL 1
    #define EV_CHILD_ENABLE 1
    #define EV_ASYNC_ENABLE 1
 The actual value is a bitset, it can be a combination of the following
-values:
+values (by default, all of these are enabled):
 =over 4
 =item C<1> - faster/larger code
 code size by roughly 30% on amd64).
 When optimising for size, use of compiler flags such as C<-Os> with
 gcc is recommended, as well as C<-DNDEBUG>, as libev contains a number of
 assertions.
+The default is off when C<__OPTIMIZE_SIZE__> is defined by your compiler
+(e.g. gcc with C<-Os>).
 =item C<2> - faster/larger data structures
 Replaces the small 2-heap for timer management by a faster 4-heap, larger
 hash table sizes and so on. This will usually further increase code size
 and can additionally have an effect on the size of data structures at
 runtime.
+The default is off when C<__OPTIMIZE_SIZE__> is defined by your compiler
+(e.g. gcc with C<-Os>).
 =item C<4> - full API configuration
 This enables priorities (sets C<EV_MAXPRI>=2 and C<EV_MINPRI>=-2), and
 enables multiplicity (C<EV_MULTIPLICITY>=1).

Diff Legend

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

Comparing libev/ev.pod (file contents): Revision 1.399 by root, Mon Apr 2 23:14:41 2012 UTC vs. Revision 1.405 by root, Thu May 3 15:07:15 2012 UTC

Diff Legend

Comparing libev/ev.pod (file contents):
Revision 1.399 by root, Mon Apr 2 23:14:41 2012 UTC vs.
Revision 1.405 by root, Thu May 3 15:07:15 2012 UTC