Vinubalaji Gopal | 16 Apr 23:33 2014

libev port crash in solaris

  I see the port based implementation crashes in solaris. I am running the latest Solaris (based on the archive suggestions) but it still seem to crash. I did find a case where it crashes immediately (which is good, otherwise it crashes randomly). Any ideas on what could be causing this?

-----------------  lwp# 21 / thread# 21  --------------------

 ffffffff7dedcb68 _lwp_kill (6, 0, ffffffff7e049c68, ffffffffffffffff, ffffffff7e03e000, 0) + 8

 ffffffff7de4c1c0 abort (1, 1d8, 0, 1f1f4c, 0, 0) + 118

 00000001000f7d50 ev_syserr (100495020, 1, 40, ffffffff7b1f12bc, 3e, f7) + 78

 00000001000f9418 port_poll (1046ed6d0, 4, 1046ed878, 5, 0, 1046effc0) + 14c

 00000001000fcb50 ev_run (1046ed6d0, 0, 104674df8, ffffffffffffffff, 0, 0) + 4bc

 000000010009f0f0 ev_loop (1046ed6d0, 0, ffffffff7b1f15c0, ffffffff7b1f15f0, 1, 0) + 20

bash-3.2# uname -a

SunOS sol220 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-V210

libev mailing list
libev <at>
Kirill Timofeev | 7 Apr 18:17 2014

libev application stops responding and consumes 100% cpu

Hi folks,

I've created libev based application, which works ok for some time, but 
at random moment it stops responding and consumes 100% cpu. Here is 
information on os and libev version:

kirill.timofeev <at> els-abacus-stage-01:~$ uname -a
Linux els-abacus-stage-01 3.8.0-37-generic #53~precise1-Ubuntu SMP Wed 
Feb 19 21:37:54 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
kirill.timofeev <at> els-abacus-stage-01:~$ dpkg -l|grep libev
ii  libev-dev                        1:4.11-1 static library, header 
files, and docs for libev
ii  libev4                           1:4.11-1 high-performance event 
loop library modelled after libevent
ii  libevent-2.0-5                   2.0.16-stable-1 Asynchronous event 
notification library
kirill.timofeev <at> els-abacus-stage-01:~$

I generated core file from frozen process. Unfortunately I'm not expert, 
so the only thing I see is that process got stuck in ev_run:

(gdb) bt
#0  0x00007f3337393583 in ev_run () from /usr/lib/
#1  0x000000000040142a in main ()

I noticed, that official already have version 4.15, while ubuntu 
repository still have 4.11.

Should I use latest code from official site or there is better way to 
resolve this issue?

Utku GENC | 1 Apr 13:39 2014

Best way to use async library jobs with the event-loop


libuv has a convenience function for using possible blocking library 
operations with event-loop paradigm*. What, do you think, is the best 
way to implement such functionality for libev?


utku genç | 1 Apr 13:51 2014

Best way to use async library jobs with the event-loop


libuv has a convenience function for using possible blocking library operations with event-loop paradigm*. What, do you think, is the best way to implement such functionality for libev?



libev mailing list
libev <at>
Jann Horn | 23 Mar 20:44 2014
Picon points to a 404 page

The "file releases" link at points
to a 404 page. Is that just a mistake or should I grab libeio from the cvs
repo instead?
libev mailing list
libev <at>
Riku Voipio | 20 Mar 11:38 2014

Aarch64 support for libev


First part of the patch adds memory fence for aarch64. Strictly, this isn't necessary, as the fallback to __atomic_thread_fence (__ATOMIC_SEQ_CST) would output the same dmb ish instruction. 

Second part makes sure the ancient arm float format doesn't get used. Originally I added an if defined(__aarch64__) like the rest, but then I thought perhaps reversing the the if else makes sense. old arm float format is so rare, that the default should be native float ordering. By selecting __arm__ and !( list of features known to identify native endian on arm ), we don't need to list all the architectures in world that not mixed-endian. The feature list was picked up from webkit and firefox.

Alternative would be to drop all ancient arm float support - anyone still using the abi wouldn't be upgrading to new libev.

Attachment (libev-aarch64.patch): text/x-patch, 2228 bytes
libev mailing list
libev <at>
Konstantin Osipov | 18 Mar 11:48 2014

Piggy-backing lock-free queue synchronization on ev_async membar


In our program we have 2 threads, both running ev_loops, and would
like to organize a simple producer-consumer message queue from one
thread to the other.
For the purpose of this discussion let's assume a message is a
simple integer.

It seems that we could implement such a data structure
in a completely lock-less manner.

Please consider the following implementation:

enum { QUEUE_SIZE = 100 };

struct queue {
        int q[QUEUE_SIZE];
        int wpos;  /* todo: cacheline aligned. */
        int rpos; /* todo: cacheline aligned */
        ev_async async;

/* Done in the producer */
queue_init(struct queue *q, ev_loop *consumer)
        q->rpos = q->wpos = 0;
        ev_async_init(&async, consumer);

/* For use in the producer thread only. */
queue_put(struct queueu *q, int i)
        if (q->wpos == QUEUE_SIZE)
                q->wpos = 0;
        q->q[q->wpos++] = i;

 * For use in the consumer thread only, in the event handler
 * for q->async.
queue_get(struct queue *q)
        if (q->rpos == QUEUE_SIZE)
                q->rpos = 0;
        return q->q[q->rpos++];

Let's put aside the problem of rpos and wpos running over each other,
for simplicity. 
The question is only, provided that QUEUE_SIZE is sufficient for
our production loads, would memory barrier built into 
ev_async_send be sufficient to ensure the correct read ordering
of this queue?


-- - an efficient, extensible in-memory data store
Konstantin Olkhovskiy | 13 Mar 17:11 2014

[ANN] Introducing libevfibers

Hello to everyone,

Please let me advertise my little project as it might be of interest to you.

libevfibers is a small C fiber library that uses libev event loop and libcoro coroutine
context switching.

Fibers are user-space threads, which enable one to have a blocking-style application,
which is actually event-loop driven and asynchronous.

The project resides on GitHub [1]. A simple example of a fiber-based socket server can
be found at [2].

It is licensed under a business-friendly Apache License, Version 2.0.
It is used in production at my work on hundreds of nodes and seems quite stable. But I
would call it 'beta' so far, just to be safe :)

If you are interested, have any questions or feedback, please use the project mailing list [3].

libev mailing list
libev <at>
Jan Kaluža | 11 Mar 14:08 2014

libeio soname conflicts with Enlightenment's Eio


as a package maintainer of some Fedora packages and co-maintainer of 
rubygem-passenger package I have found out that rubygem-passenger needs 
libeio to work.

I wanted to package libeio for Fedora and found out that the Eio library 
provided by Enlightenment [1] conflicts with your libeio library. This 
library uses the same soname as your libeio and therefore it's not 
possible to package your library for Fedora.

I think the same situation will exist with other distributions too.

I wanted to ask upstream developers, if they are aware of that and if 
there is some chance to get this fixed somehow (maybe renaming libeio?). 
I think that it's easier to rename your libeio, becuase Enlightenment is 
more widely used and is already in the most distributions.


Jan Kaluza
Mikkel Kroman | 8 Mar 06:05 2014

EV_FD_TO_WIN32_HANDLE on Windows

Hi, I'm currently experiencing the same problem as explained here:

Was this issue ever acknowledged or resolved?

The fh getting passed to _get_osfhandle is 144, while _nhandle is always 32.

This is happening when running Windows 8.1 with the Visual Studio 2013 runtime.

Mikkel Kroman
libev mailing list
libev <at>
Jafar habibi livar | 2 Mar 16:09 2014

number of watcher

I should thanks for your quick reply.
how can I find number of watchers which already registered in loop?

thanks a lot
libev mailing list
libev <at>