Denis Denisov | 10 Aug 05:07 2015

libev-4.20, ev.h: fatal error: expected identifier

# cc --version
clang version 3.6.0
Thread model: posix

In file included from /usr/local/include/ev++.h:46:
/usr/local/include/ev.h:240:3: fatal error: expected identifier
  EV_ERROR    = (int)0x80000000  /* sent when an error occurs */
/usr/include/sys/event.h:86:18: note: expanded from macro 'EV_ERROR'
#define EV_ERROR        0x4000          /* error, data contains errno */
1 error generated.
*** Error code 1

[ev.c:4827] -> [ev.c:4821]: (warning) Possible null pointer
dereference: once - otherwise it is redundant to check it against
[ev.c:4828] -> [ev.c:4821]: (warning) Possible null pointer
dereference: once - otherwise it is redundant to check it against
[ev.c:3520]: (warning) Assert statement modifies 'loop_done'.
[ev.c:3522]: (warning) Assert statement modifies 'loop_done'.


Denis Denisov
Attachment (darwin-warning.log): application/octet-stream, 23 KiB
(Continue reading)

Thomas Petazzoni | 8 Aug 23:50 2015

[PATCH] Fix SPARCv8 condition

Fix SPARCv8 condition

The define provided by the compiler on SPARCv8 is __sparc_v8__ and not
__sparcv8. From a SPARCv8 gcc:

$ sparc-linux-gcc --version
sparc-linux-gcc (Buildroot 2015.08-git-00497-ge110081) 4.9.3
$ sparc-linux-gcc -dM -E - < /dev/null | grep sparc
#define sparc 1
#define __sparc__ 1
#define __sparc 1
#define __sparc_v8__ 1

Signed-off-by: Thomas Petazzoni <thomas.petazzoni <at>>

Index: b/ev.c
--- a/ev.c
+++ b/ev.c
 <at>  <at>  -649,7 +649,7  <at>  <at> 
       #define ECB_MEMORY_FENCE         __asm__ __volatile__ ("dmb"      : : : "memory")
     #elif __aarch64__
       #define ECB_MEMORY_FENCE         __asm__ __volatile__ ("dmb ish"  : : : "memory")
-    #elif (__sparc || __sparc__) && !__sparcv8
+    #elif (__sparc || __sparc__) && !__sparc_v8__
       #define ECB_MEMORY_FENCE         __asm__ __volatile__ ("membar #LoadStore | #LoadLoad | #StoreStore |
#StoreLoad" : : : "memory")
       #define ECB_MEMORY_FENCE_ACQUIRE __asm__ __volatile__ ("membar #LoadStore | #LoadLoad"                            : : : "memory")
       #define ECB_MEMORY_FENCE_RELEASE __asm__ __volatile__ ("membar #LoadStore             | #StoreStore")
(Continue reading)

Zsbán Ambrus | 8 Aug 18:05 2015

Libecb: notes about alignas and alignof

I'd really like a portable way to use alignof and alignas.  This seems
impossible, especially on old compilers, but I still think libecb
might still try to help in some cases.  I don't know the final
solution of what could be done, so here I'm trying to collect
information about what compilers support what features, and how you
can test them without a configure system.  I'll take alignof and
alignas separately.  These are mostly symmetric, but have differences.

== alignof ==
The C++11 alignof keyword queries the required alignment of a type.

1. The alignof keyword is available in C++11, C++ in starting from gcc
4.8, C++ in clang if __has_feature(cxx_alignas), but not yet in any
version of the MS compiler.
2. The _Alignof keyword, and the macro alignof in <stdalign.h>, is
available in C11, and I don't know the compiler versions.
3. The GCC __alignof__ keyword is available starting from ancient
times (before gcc 3).
4. The MS compiler has an __alignof keyword.
5. The std::alignment_of template in <type_traits> would be a suitable
replacement to alignof, but it's probably only available in C++11
compilers that have alignof anyway.
6. Boost has an implementation of the alignment_of in the TypeTraits
library for some compilers, unknown header and namespace, which might
give some hints if only you could untangle the source code.
7. The boost config module has some macros like BOOST_NO_CXX11_ALIGNAS
that try to tell whether compilers have C++11 alignas, but it's hard
to read the boost source code to find out how this works, and it's
sometimes not precise, so it's useful only as a starting point.

(Continue reading)


repeating topic : detectect uncleanly closed socket

Hi all

I finally managed my implementation of an multi-threaded socket server 
with libev.

Now there is one thing left: detecting uncleanly disconnected sockets.

At the moment the approach of the client is the following:

1x ioReadWatcher
1x ioWriteWatcher
1x stopWatcher
1x timerWatcher called every 10/20/30 sec

I'm looking for a nice approach to implement the detection, as my 
devices are on a mobile network, due to this might loose connection.

Reconnect is cleanly handled.
But if the socket disconnects uncleanly, the timer keeps running and the 
client is kept open...

What is the suggested approach to implement this.
Any suggestions and code snippets are highly welcome!

Thanks in advance


libev mailing list
(Continue reading)

Cheyi Lin | 30 Jul 17:48 2015

How does libev invoke an io watcher if both EV_READ and EV_WRITE are pending?

If both EV_READ and EV_WRITE are pending, libev will ...

1) invoke the callback twice, one is for EV_READ, the other is for EV_WRITE.
2) invoke the callback once, revents |= (EV_READ | EV_WRITE).

Which is correct? Thanks.

Cheyi Lin

libev mailing list
libev <at>
Morand, Guy | 6 Jul 15:09 2015


Hello libev developpers!

I'm writing a little application to monitor GPIO status on my embedded Linux device. I wanted to give libev a
try, on the paper it looks really cool and fast.

However, to monitor a GPIO line, I need to get the  EXCEPTION event from select or the POLLPRI from poll.
Unfortunately this event doesn't seem to be implemented in libev and I can't use it out of the box. 

Before trying to change something, I wanted to see with you if there is there any reasons for no implementing
this event? What are the constraints and the limitations?

Kind regards,

Guy Morand

libev mailing list
libev <at>

Questions - partly newbie

Hi all

I'm new to event loops and am wondering about a couple of things...
Maybe somebody will clarify the questions for me. I'm using ev++ for 
implementation, if this is of interest.

I'm implementing a TCP-Socket Server on Linux to which a large number of 
embedded devices is connecting and reporting status every 10-60sec.

The current architecture spawns a thread for the server, accepting 
connections in an own ev::default_loop.
The server there is 2x ev:signal and 1x ev::io(ev::READ) for accepting 

On accepting the client gets it's own thread with an ev::dynamic_loop.
For the client I'm using 2x ev::io (1x ev::READ, 1x ev::WRITE), 1x 
ev::timer, 1x ev::async for stopping.

1. When running an event loop with multiple watchers, per iteration only 
one watcher is called - is this intended or is my implementation wrong?

2. Having the ev::timer running, at some point the ev::io watchers stop 
working. are the watcher excluding each other?

3. Sometimes the latency is extremly high, when accepting connections. I 
can't really find a reason for this. Any hints?

4. Is there any known difference between ev++ and ev I should be caring 

(Continue reading)

Dejan Markic | 22 May 15:26 2015

Some questions about libev


I'm writing multi-threaded C client with hiredis and their libev adapter. I'm using multi-threading,
because I have several servers to which I send the same command and await their reply.

First of all, there is no ev default loop. Each ev loop is initialized in main thread and is then passed on to
pthread_create (along with other stuff like watchers, etc). 
Once the thread starts, it create hiredis async handler and attaches libev with its libev handler and sets
up all the callbacks.
After all is initialized and connected, I send commands from main thread to all servers via redisAsyncCommand.


1. Hiredis libev adapter uses two ev_io watchers, one for reading and one for writing. It's simply calling
start and stop on those watchers based on what it tries to do.
    This does not work for me, unless I register another ev_async watcher, that fires everytime hiredis tries
to start/stop the io_watcher. Is that expected? I would say that once
    libev goes into poll/select/etc wait, it will not move out of wait if you stop the watcher, or start the
stopped watcher, right?

2. I tried another approach I saw on the internet. Single ev_io watcher, but everytime hiredis tries to
stop/start read/write, I to ev_io_stop(...) and then I set EV_READ and/or EV_WRITE flags via ev_io_set
and then ev_io_start again. Also in that case, I need ev_async watcher to wakeup the libev. Would you that
that single IO watcher approach would be better?

Both 1. and 2. I tried protecting changes in watchers with mutex, but no success. 

3. My test program hangs after few minutes, maybe even few seconds (it's working for atleast 1000
iterations, even 100000 sometimes) after I fire it (sending SET/GET to one or many servers). It hangs in
epoll_wait or select (tried different EVBACKEND_*). It doesn't receive the ev_async event it seems. I
(Continue reading)

Marc Lehmann | 22 May 09:49 2015

Re: ev_periodic like functionality for time intervals

On Wed, May 20, 2015 at 11:57:31PM +0200, Thilo Schulz <thilo <at>> wrote:
> > The most compatible/conceptually simple solution would be to simply have
> > a one-minute timer or so and check for the interval yourself, which might
> Hmm, time jumps will only be the exception that I want to catch if they 
> happen. I still want to trigger on entering the interval as soon as possible, 
> so to have a second watcher, a timer watcher in addition to the periodic is a 
> bit ugly in my opinion.

No, this suggestion was really only having one ev_timer, and checking for
interval crossings inside, you wouldn't have an extra ev_periodic watcher:

   int on;

   timer_callback (...)
      int hour = get_hour ();

      int new_on = hour < 10 || hour > 22;

      if (new_on != on)
          on = new_on;
          state changed!

It's the simple hack that I wouldn't use if you use if you had many of

(Continue reading)

Andrey Pokrovskiy | 22 May 06:43 2015

Strict aliasing rule strikes back


When I include ev.h in my c++ code (gcc 4.9, -std=c++11 -Wall -Wextra
-Werror -pedantic-errors -O3) I get strict aliasing warning.

But I'm not saying that there is something wrong with libev and that
those warnings should be fixed asap (surprise-surprise).

I'm just curious why libev needs all those casts that produce that
warning in a first place. For example, why not to have it that way:

#define ev_init(ev,cb_) do {                   \
-  ((ev_watcher *)(void *)(ev))->active  =      \
-  ((ev_watcher *)(void *)(ev))->pending = 0;   \
+  (ev)->active  = \
+  (ev)->pending = 0;   \
  ev_set_priority ((ev), 0);                   \
  ev_set_cb ((ev), cb_);                       \
  ev_set_cb ((ev), cb_);                               \
} while (0)

Since ev must be a watcher, it will have "active" and "pending"
members and two-steps cast is not really necessary. Another example:

-# define ev_set_cb(ev,cb_)                   (ev_cb_ (ev) = (cb_), memmove (&
                          ((ev_watcher *)(ev))->cb, &ev_cb_ (ev),
sizeof (ev_cb_ (ev))))
+# define ev_set_cb(ev,cb_)                   (ev)->cb = (cb_)

Why to use memmove when "ev->cb" and "cb_" must have the same type and
(Continue reading)

Thilo Schulz | 20 May 04:06 2015

ev_periodic like functionality for time intervals

Dear list, der Mr. Lehman,

for my program, I need some kind of output variable which shall have two 
states depending on wall clock time:

- 22:00 to 10:00: off
- 10:00 to 22:00 on

and a callback that is to be called upon change of this state.
An ev_periodic watcher seems to be ideal here.
If I understand the documentation correct, a state change would be detected 
if, for instance, PC time jumps from, say
2015-05-19 13:00:00 to 2015-05-19 23:00:00
but not if PC time jumps backwards like
2015-05-19 23:00:00 to 2015-05-18 13:00:00
which is of course undesirable.

I guess in the latter case, I will need to detect a time jump backwards by, 
for instance, comparing the return value of ev_now() with the return value of 
ev_now() from a previous event loop iteration in an ev_check watcher.

Just want to avoid any unpleasant surprises.

Best regards,
Thilo Schulz

libev mailing list
libev <at>
(Continue reading)