*** empty log message ***

diff --git a/Changes b/Changes
index 20e7bd64edd6409430652d3502528362ee4547b0..6efc4a761f5cc59ec6d1f51c211e5833bc395cfb 100644 (file)
--- a/Changes
+++ b/Changes
@@ -11,10 +11,11 @@ TODO: store pid for each signal
 TODO: document file descriptor usage per loop
 TODO: store loop pid_t and compare isndie signal handler,store 1 for same, 2 for differign pid, clean up in loop_fork
 TODO: embed watchers need updating when fd changes
-TODO: document portbaility requirements for atomic pointer access
+TODO: document portability requirements for atomic pointer access
 TODO: possible cb aliasing?
-TODO: document requirements for function piinters and calling conventions.
+TODO: document requirements for function pointers and calling conventions.
 
+4.18 Fri Sep  5 17:55:26 CEST 2014
        - events on files were not always generated properly with the
           epoll backend (testcase by Assaf Inbal).
        - mark event pipe fd as cloexec after a fork (analyzed by Sami Farin).

diff --git a/ev.3 b/ev.3
index c254fc6847dbe7da361b3a9970b78f7235294c85..829e7fbec40cd81f19eb6f50a713d04ae7cae70b 100644 (file)
--- a/ev.3
+++ b/ev.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\" Automatically generated by Pod::Man 2.28 (Pod::Simple 3.28)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
@@ -133,7 +133,7 @@
 .\" ========================================================================
 .\"
 .IX Title "LIBEV 3"
-.TH LIBEV 3 "2013-12-27" "libev-4.15" "libev - high performance full featured event loop"
+.TH LIBEV 3 "2014-09-05" "libev-4.15" "libev - high performance full featured event loop"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -812,11 +812,12 @@ If you need dynamically allocated loops it is better to use \f(CW\*(C`ev_loop_ne
 and \f(CW\*(C`ev_loop_destroy\*(C'\fR.
 .IP "ev_loop_fork (loop)" 4
 .IX Item "ev_loop_fork (loop)"
-This function sets a flag that causes subsequent \f(CW\*(C`ev_run\*(C'\fR iterations to
-reinitialise the kernel state for backends that have one. Despite the
-name, you can call it anytime, but it makes most sense after forking, in
-the child process. You \fImust\fR call it (or use \f(CW\*(C`EVFLAG_FORKCHECK\*(C'\fR) in the
-child before resuming or calling \f(CW\*(C`ev_run\*(C'\fR.
+This function sets a flag that causes subsequent \f(CW\*(C`ev_run\*(C'\fR iterations
+to reinitialise the kernel state for backends that have one. Despite
+the name, you can call it anytime you are allowed to start or stop
+watchers (except inside an \f(CW\*(C`ev_prepare\*(C'\fR callback), but it makes most
+sense after forking, in the child process. You \fImust\fR call it (or use
+\&\f(CW\*(C`EVFLAG_FORKCHECK\*(C'\fR) in the child before resuming or calling \f(CW\*(C`ev_run\*(C'\fR.
 .Sp
 Again, you \fIhave\fR to call it on \fIany\fR loop that you want to re-use after
 a fork, \fIeven if you do not plan to use the loop in the parent\fR. This is
@@ -2163,15 +2164,17 @@ The relative timeouts are calculated relative to the \f(CW\*(C`ev_now ()\*(C'\fR
 time. This is usually the right thing as this timestamp refers to the time
 of the event triggering whatever timeout you are modifying/starting. If
 you suspect event processing to be delayed and you \fIneed\fR to base the
-timeout on the current time, use something like this to adjust for this:
+timeout on the current time, use something like the following to adjust
+for it:
 .PP
 .Vb 1
-\&   ev_timer_set (&timer, after + ev_now () \- ev_time (), 0.);
+\&   ev_timer_set (&timer, after + (ev_time () \- ev_now ()), 0.);
 .Ve
 .PP
 If the event loop is suspended for a long time, you can also force an
 update of the time returned by \f(CW\*(C`ev_now ()\*(C'\fR by calling \f(CW\*(C`ev_now_update
-()\*(C'\fR.
+()\*(C'\fR, although that will push the event time of all outstanding events
+further into the future.
 .PP
 \fIThe special problem of unsynchronised clocks\fR
 .IX Subsection "The special problem of unsynchronised clocks"
@@ -3050,13 +3053,13 @@ Prepare and check watchers are often (but not always) used in pairs:
 prepare watchers get invoked before the process blocks and check watchers
 afterwards.
 .PP
-You \fImust not\fR call \f(CW\*(C`ev_run\*(C'\fR or similar functions that enter
-the current event loop from either \f(CW\*(C`ev_prepare\*(C'\fR or \f(CW\*(C`ev_check\*(C'\fR
-watchers. Other loops than the current one are fine, however. The
-rationale behind this is that you do not need to check for recursion in
-those watchers, i.e. the sequence will always be \f(CW\*(C`ev_prepare\*(C'\fR, blocking,
-\&\f(CW\*(C`ev_check\*(C'\fR so if you have one watcher of each kind they will always be
-called in pairs bracketing the blocking call.
+You \fImust not\fR call \f(CW\*(C`ev_run\*(C'\fR (or similar functions that enter the
+current event loop) or \f(CW\*(C`ev_loop_fork\*(C'\fR from either \f(CW\*(C`ev_prepare\*(C'\fR or
+\&\f(CW\*(C`ev_check\*(C'\fR watchers. Other loops than the current one are fine,
+however. The rationale behind this is that you do not need to check
+for recursion in those watchers, i.e. the sequence will always be
+\&\f(CW\*(C`ev_prepare\*(C'\fR, blocking, \f(CW\*(C`ev_check\*(C'\fR so if you have one watcher of each
+kind they will always be called in pairs bracketing the blocking call.
 .PP
 Their main purpose is to integrate other event mechanisms into libev and
 their use is somewhat advanced. They could be used, for example, to track
@@ -3360,7 +3363,7 @@ used).
 \&   struct ev_loop *loop_hi = ev_default_init (0);
 \&   struct ev_loop *loop_lo = 0;
 \&   ev_embed embed;
-\&   
+\&
 \&   // see if there is a chance of getting one that works
 \&   // (remember that a flags value of 0 means autodetection)
 \&   loop_lo = ev_embeddable_backends () & ev_recommended_backends ()
@@ -3386,7 +3389,7 @@ kqueue implementation). Store the kqueue/socket\-only event loop in
 \&   struct ev_loop *loop = ev_default_init (0);
 \&   struct ev_loop *loop_socket = 0;
 \&   ev_embed embed;
-\&   
+\&
 \&   if (ev_supported_backends () & ~ev_recommended_backends () & EVBACKEND_KQUEUE)
 \&     if ((loop_socket = ev_loop_new (EVBACKEND_KQUEUE))
 \&       {
@@ -3413,7 +3416,7 @@ of course.
 \fIThe special problem of life after fork \- how is it possible?\fR
 .IX Subsection "The special problem of life after fork - how is it possible?"
 .PP
-Most uses of \f(CW\*(C`fork()\*(C'\fR consist of forking, then some simple calls to set
+Most uses of \f(CW\*(C`fork ()\*(C'\fR consist of forking, then some simple calls to set
 up/change the process environment, followed by a call to \f(CW\*(C`exec()\*(C'\fR. This
 sequence should be handled by libev without any problems.
 .PP
@@ -4247,7 +4250,7 @@ Example: use a functor object as callback.
 \&       ...
 \&     }
 \&   }
-\&    
+\&
 \&   myfunctor f;
 \&
 \&   ev::io w;

diff --git a/ev.c b/ev.c
index 03b697a8338fae8f552a6226adce732f20c6761c..c8faa4bdf375e40e918a032a30fd05badfdc4048 100644 (file)
--- a/ev.c
+++ b/ev.c
@@ -807,11 +807,18 @@ typedef int ecb_bool;
   #define ecb_decltype(x) __typeof(x)
 #endif
 
+#if _MSC_VER >= 1300
+  #define ecb_deprecated __declspec(deprecated)
+#else
+  #define ecb_deprecated ecb_attribute ((__deprecated__))
+#endif
+
 #define ecb_noinline   ecb_attribute ((__noinline__))
 #define ecb_unused     ecb_attribute ((__unused__))
 #define ecb_const      ecb_attribute ((__const__))
 #define ecb_pure       ecb_attribute ((__pure__))
 
+/* http://msdn.microsoft.com/en-us/library/k6ktzx3s.aspx __declspec(noreturn) */
 #if ECB_C11
   #define ecb_noreturn   _Noreturn
 #else

diff --git a/ev.h b/ev.h
index 38a507e13a38b68a8f8513b64618bccb7a09eb14..13d22ed18999c370c60d760b718613c833717b7f 100644 (file)
--- a/ev.h
+++ b/ev.h
@@ -205,7 +205,7 @@ struct ev_loop;
 /*****************************************************************************/
 
 #define EV_VERSION_MAJOR 4
-#define EV_VERSION_MINOR 15
+#define EV_VERSION_MINOR 18
 
 /* eventmask, revents, events... */
 enum {