Nick Zavaritsky | 23 Nov 14:20 2015

coro: Asm coro_transfer for arm7


Please consider the patch implementing CORO_ASM backend for arm7 arch.

Attachment (coro_transfer_arm7.patch): application/octet-stream, 4189 bytes
libev mailing list
libev <at>
Zsbán Ambrus | 19 Nov 14:32 2015

libecb: PATCH ecb_ld* to use MSC intrinsics


I attach an attempt to patch libecb so that it uses the MSC (MS
compiler) intrinsic functions to implement the bit manipulation
functions ecb_ld32, ecb_ld64, ecb_ctz32, ecb_ctz64.

The patch seems to work for me on MSC, but needs a bit more testing on
other compilers to make sure I didn't accidentally break the code.

I suggest using the code below to test the return values of the
functions.  Test in C and C++ mode.  This may be worth to add to a
separate test file distributed with libecb, just like the previous
test file for the alignment stuff.

-- Ambrus

/* Test ctz and ld functions  */
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include "ecb.h"

ecb_inline int generic_ctz32(uint32_t x)
    int r = 0;
    x &= ~x + 1; /* this isolates the lowest bit */
    if (x & 0xaaaaaaaa) r +=  1;
    if (x & 0xcccccccc) r +=  2;
    if (x & 0xf0f0f0f0) r +=  4;
    if (x & 0xff00ff00) r +=  8;
(Continue reading)

Thorsten Lück | 18 Nov 17:38 2015

Question on using C++ API

Hi  <at> all,

I want to write a small embedded application listing on UDP. It is
compiling using the C-Api but not using the C++-Api. In both cases I am
using the gnu g++ compiler:

> $ /opt/crosstool-ng-powerpc/bin/powerpc-e500v2-linux-gnuspe-g++ --version
> powerpc-e500v2-linux-gnuspe-g++ (crosstool-NG 1.16.0-WORK-1.0) 4.6.0
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO


// This callback is called when data is readable on the UDP socket.
static void
udp_cb (EV_P_ ev_io *w, int revents)
    puts("udp socket has become readable");
    socklen_t bytes = recvfrom(sd, buffer, sizeof(buffer) - 1, 0,
(struct sockaddr*) &addr, (socklen_t *) &addr_len);

    // add a null to terminate the input, as we're going to use it as a
    buffer[bytes] = '\0';

    printf("udp client said: %s", buffer);

    // Echo it back.
    // WARNING: this is probably not the right way to do it with libev.
(Continue reading)

jang | 11 Nov 08:46 2015

on license terms of libev.

Hi Marc,

I have a plan to use libev in my developing program for commercial.
However, I cannot find any license terms in your website.

As open source, is it possible to use freely it without any limitation?
If not, would you tell me terms of license?

Jang YH,  from Seoul.

Jang, Young-ho
email : goodjang <at>
Mobile : 010-7999-0586

libev mailing list
libev <at>
Vladimir Ivannikov | 10 Nov 21:28 2015

invalid win32 accept() check in ev_pipe


There is tiny bug in win32 implementation of ev_pipe() caused by the 
fact that accept() returns SOCKET type which is actually UINT_PTR on 
windows which of couse unsigned and can't be
signed compared with 0 (compiler will just optimized this check out)
Patch is trivial:

Index: ev_win32.c
RCS file: /schmorpforge/libev/ev_win32.c,v
retrieving revision 1.17
diff -u -3 -w -r1.17 ev_win32.c
--- ev_win32.c    17 Oct 2015 21:47:56 -0000    1.17
+++ ev_win32.c    10 Nov 2015 20:21:53 -0000
 <at>  <at>  -88,7 +88,7  <at>  <at> 
    if (connect (sock [0], (struct sockaddr *)&addr, addr_size))
      goto fail;

-  if ((sock [1] = accept (listener, 0, 0)) < 0)
+  if ((sock [1] = accept (listener, 0, 0)) == INVALID_SOCKET)
      goto fail;

    /* windows vista returns fantasy port numbers for sockets:

libev mailing list
libev <at>
Jason Madden | 17 Oct 01:38 2015

Compilation Error Under Visual Studio 14 on Windows (fixed)

Hi all,

I'm a maintainer of the Python library gevent which wraps libev. When compiling the latest release of libev
using the relatively-recently-released Visual Studio 14 (aka 2015) for both 32- and 64-bit
environments we got compilation errors like these:

C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\sys/timeb.h(25): error C2032:
'__timezone': function cannot be member of struct '__timeb32' 
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\sys/timeb.h(33): error C2032:
'__timezone': function cannot be member of struct '__timeb64' 
C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\sys/timeb.h(42): error C2032:
'__timezone': function cannot be member of struct 'timeb' 

Our solution was to remove the include of <sys/timeb.h> in ev_win32.c. (As far as I can tell, that hasn't
been necessary since sometime in 2009 when the code was changed to use GetSystemTimeAsFileTime.) After
that, libev compiles and runs using Visual Studio 14, Visual Studio C++ 9 For Python, Visual Studio 9, and
Visual Studio 10. timeb.h is noted to contain "xsi legacy functionality", so I'm not sure if it's not being
maintained properly anymore, or exactly what the issue was (I don't have access to debug on the windows
virtual machine in use because it's a CI server, I just get the build logs)---all I know is that taking out
the import fixed the problem.

I hope this is a helpful report.

libev mailing list
libev <at>
Benjamin Mahler | 9 Oct 20:55 2015

Bug Report: SIGPIPE during call to ev_async_send

Hi Marc,

First of all, thanks for the great library, the Mesos project has been using heavily in production for many years. Recently, we've encountered a rare issue in which SIGPIPE occurs during a call to ev_async_send.

The environment is CentOS 5 (no eventfd, and epolll backend). The call to write() against evpipe[1] in evpipe_write triggers a SIGPIPE, indicating that evpipe[0] is closed.

The bug is rare (on the order of 10 occurrences per day on production clusters of tens of thousands of servers). We initially suspected that there was a rogue close in the non-libev code (e.g. double close on an fd) that was accidentally closing evpipe[0] due to fd reuse.

However, having ruled out bad close calls within our code, I started digging into libev and noticed what appears to be the bug. Consider the following situation:

Thread1 (in ev_run): backend_poll -> epoll_poll -> sets postfork = 1
Thread1 (in ev_run): return from backend_poll, but before setting pipe_write_wanted = 0
Thread2 (in ev_async_send): evpipe_write -> sees pipe_write_wanted = 1 and enters the if block
Thread1 (in ev_run): comes back to top of the loop and checks postfork, calls loop_fork and closes evpipe[0] but does not yet call evpipe_init
Thread2 (in ev_async_send): evpipe_write continues and calls write() -> SIGPIPE

To test this theory, we inserted usleep calls in the three locations to increase the likelyhood of the race occurring during our test suite. Here is a diff against ev.c revision 1.477:

$ diff ev.c ev.c.sleeps
>       usleep(1000);
>       usleep(10000);
>         usleep(10);

If easier, here is a gist in which you can find the injected sleeps by looking for "usleep":

Once these are injected, our test suite regularly trips the SIGPIPE:

W0100 00:00:00.000000 41361 main.cpp:38] RAW: Received signal SIGPIPE; escalating to SIGABRT
*** Aborted at 1444415504 (unix time) try "date -d <at> 1444415504" if you are using GNU date ***
PC: <at>     0x7fb365a75b6d raise
*** SIGABRT ( <at> 0xa191) received by PID 41361 (TID 0x7fb367984780) from PID 41361; stack trace: ***
    <at>     0x7fb365a75ca0 (unknown)
    <at>     0x7fb365a75b6d raise
    <at>           0x4e51d9 handler()
    <at>     0x7fb365a75ca0 (unknown)
    <at>     0x7fb365a74a2b __libc_write
    <at>           0x40ad3b evpipe_write.part.5
    <at>           0x77ce9d process::run_in_event_loop<>()

This seems to confirm the issue! With eventfd enabled the write will silently fail rather than trigger SIGPIPE. This also seems problematic, yes?

Looking forward to hearing your thoughts Marc!
libev mailing list
libev <at>
Nick Zavaritsky | 6 Oct 17:05 2015

libeio broken in revision 1.139

Hi Marc,

We’ve updated to the latest libeio and we were very upset due to it crashing in etp_poll like crazy.

The problem was due to want_poll/done_poll callbacks missing in the internal etp_pool object, obviously
eio_init isn’t setting them.

Attaching a patch to illustrate the point.

Please have a nice day.
Attachment (libeio.cb.patch): application/octet-stream, 784 bytes
libev mailing list
libev <at>
黄东文 | 18 Sep 10:59 2015

a bug?

hi all:

                   in eio.c ,line num:2209,  has a bug:when goto quit, do you forget to --started?

libev mailing list
libev <at>
Zsbán Ambrus | 9 Sep 11:28 2015

Ecb: unaligned integer load and store support

Code for unaligned integer load and store.  This should eventually go
to libecb.  Be vary of the code, I haven't really tested it, it's
probably full of typos.  Also, no documentation yet.

struct ecb_array_u8_8 { uint8_t ecb_e[8]; };
union ecb_union_u64 { ecb_array_u8_8 ecb_a; uint64_t ecb_v; };
ecb_inline uint64_t ecb_load_u64(const void *ecb_p)
    union ecb_union_u64 ecb_u;
    ecb_u.ecb_a = *(const ecb_array_u8_8 *)ecb_p;
    return ecb_u.ecb_v;
ecb_inline void ecb_store_u64(void *ecb_p, uint64_t ecb_x)
    union ecb_union_u64 ecb_u;
    ecb_u.ecb_v = ecb_x;
    *(ecb_array_u8_8 *)ecb_p = ecb_u.ecb_a;
struct ecb_array_u8_4 { uint8_t ecb_e[4]; };
union ecb_union_u32 { ecb_array_u8_4 ecb_a; uint32_t ecb_v; };
ecb_inline uint32_t ecb_load_u32(const void *ecb_p)
    union ecb_union_u32 ecb_u;
    ecb_u.ecb_a = *(const ecb_array_u8_4 *)ecb_p;
    return ecb_u.ecb_v;
ecb_inline void ecb_store_u32(void *ecb_p, uint32_t ecb_x)
    union ecb_union_u32 ecb_u;
    ecb_u.ecb_v = ecb_x;
    *(ecb_array_u8_4 *)ecb_p = ecb_u.ecb_a;
struct ecb_array_u8_2 { uint8_t ecb_e[2]; };
union ecb_union_u16 { ecb_array_u8_2 ecb_a; uint16_t ecb_v; };
ecb_inline uint16_t ecb_load_u16(const void *ecb_p)
    union ecb_union_u16 ecb_u;
    ecb_u.ecb_a = *(const ecb_array_u8_2 *)ecb_p;
    return ecb_u.ecb_v;
ecb_inline void ecb_store_u16(void *ecb_p, uint16_t ecb_x)
    union ecb_union_u16 ecb_u;
    ecb_u.ecb_v = ecb_x;
    *(ecb_array_u8_2 *)ecb_p = ecb_u.ecb_a;

// -- Ambrus

libev mailing list
libev <at>
Zsbán Ambrus | 5 Sep 01:10 2015

Ecb: alignas and alignof support

I've prepared a patch and test to add alignas and alignof support to
the ecb library.  This is "ecb-alignas0.patch", attached to this mail.

While making this patch, I found out a lot about strange behavior of
certain compilers, but probably not everything, so there may still be

I've made a test program "ecb_align_test.c" that can check some of the
behavior of the patch.  After patching libecb.h, please compile and
run the test program with whatever compiler you have available, and
see if it works.  I recommend that you try to compile it separately as
a C source and a C++ source, because the patch should work in both
cases, but the language and available features differ.  I also
recommend that you build in both a C11 and C99 mode, and both a C++11
(or later) and C++98 mode, if your compiler has such an option.  I
will test with msvc 2013 next week.  The program should compile, and
when ran, print "Alignas test ok." after some other debug information.
If you get a failure, please report on the mailing list, possibly with
a patch.

Some notes about the implementation.
1. I do not check for the version of gcc, because even on a new enough
version there seems to be no way to use alignas or _Alignas in C99 or
C++98 mode.
2. Msvc gives an error to a declaration like __declspec(align(1))
__declspec(align(64)) which is why I insist on no doubled
3. Clang gives a syntax error to a declaration like
__attribute__((unused)) alignas(64) char x; which is why the
documentation insists that ecb_alignas(v) much come before ecb_unused.
4. I don't allow putting the ecb_alignas(v) after a variable name,
because MSC gives a syntax error to a declaration like int x
5. I haven't tried more exotic compilers, or old versions of
compilers, at all.  It's likely that there will be failures on some
compilers other than gcc, clang, msc.

Attachment (ecb-alignas0.patch): text/x-diff, 4676 bytes
Attachment (ecb_align_test.c): text/x-csrc, 2699 bytes
libev mailing list
libev <at>