Knut Olav Bøhmer | 24 May 07:09 2016
Picon
Gravatar

./confiugre options

Hi,

I'm debugging some code that works on mac but not on linux
so I would like to compile libev without different features, like eventfd, signalfd, epoll etc. to see if any of this makes a difference.
Are there any options to the configure script to do that?


regards
--
Knut Olav Bøhmer

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Jose Madrigal | 20 May 21:01 2016
Picon

ev_async race condition??

Hi!! I'm using libev in a multithreading project and I'm debugging with ThreadSanitizer from clang.  The ThreadSanitizer says there is a data race in libev, but i'm not sure if it is a false positive.

I'm wake up a event loop using ev_async because belongs to another thread. This is not supposed cause races.

This is the traceback that ThreadSanitizer throw:

thread 1 (perform a Write)
#0 evpipe_write - ev.c:2443
#1 ev_async_send - ev.c:4912
#2 ev::async::send() - ev++.h:801

thread 2 (perform a Read)
#0 ev_run - ev.c:3613

And then when I take a look on those files the variable that apparently races is "pipe_write_skipped" but in the code looks like is a "sig_atomic_t" type that should not be causing races.

Is there any chances that this race condition is real or is just a false positive??

Sorry if I was not clear enough or I misspoke, english is not my strong



_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Robert Eisele | 18 May 02:29 2016
Gravatar

libev featured fifo

Hi,

I wanted to create a simple non-blocking fifo using libev. It works
great, but when I strace the process, I see a lot of epoll_waits
directly accepting 0 byte reads after the first byte was read. Is this a
problem with libev or am I missing something?

In more detail, the code can be found here: http://pastebin.com/2NUTkPNb

And what I see on strace is this occuring a lot:

epoll_wait(3, {{EPOLLHUP, {u32=5, u64=4294967301}}}, 64, 59743) = 1
epoll_ctl(3, EPOLL_CTL_MOD, 5, {EPOLLIN, {u32=5, u64=4294967301}}) = 0
clock_gettime(CLOCK_MONOTONIC, {43720, 29238758}) = 0
read(5, "", 130)                        = 0

I'd like to put the process asleep again when everything was read. Is
there a way to accomplish that?

Thanks!

Robert

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Eric Fowler | 12 May 00:22 2016

Using libev with Windows sockets

I have inherited a pretty large Linux-based server project and am tasked with porting it to Windows. It is heavily dependent upon libev and libeio.

 

(1)    - I have noticed that libev uses socket descriptors as array indexes in several places. This is fine on Linux because the socket descriptors are always small (typical values range from 4 to 8 for small numbers of sockets). However, Windows socket handles have integer values starting at nearly 200, with the high value undefined. This would seem to make them useless as array indices. Am I justified in my concern or is there something about Winsock or libev that I am not seeing?

(2)    – Our code is getting a Windows socket descriptor and passing it down into libev, where it comes a-cropper on an EV_FD_TO_WIN32_HANDLE() macro in ev.c!fd_reify() [line 2084]. I am not surprised that the macro choked; it is trying to convert a windows socket descriptor to a windows socket descriptor, which should not be expected to work. The bigger question is, ‘What am I doing wrong?’ Should I not expect the libev code to *ever* see a windows socket handle? There must be some design strategy WRT windows handles here, but I am not seeing it. The code is within an #ifdef block that expects Windows … does this mean it does not expect to see windows handles? Is there a simple way to fish a BSD style socket descriptor out of a windows socket handle?

 

Thanks very much

 

WW

 

The information in this email, and any attachments, may contain confidential information and is intended solely for the attention and use of the named addressee(s). It must not be disclosed to any person(s) without authorization. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain this message or any part of it. If you have received this communication in error, please notify me immediately.
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Opera Wang | 19 Apr 14:24 2016
Picon
Gravatar

Find active watchers

Hi,
    I'm currently using the Perl binding EV, together with modules like IO::Stream, IO::AIO, Promises, & Mojo to implement a distributed test system. The issue I had was some times the main loop EV::run can't exit when all test done because some watchers are still active.  As watchers can be created on the fly, and some of them are created by other modules, so is there any way to tell what are the active watchers and where there were created?

     And thanks for the great work.

Thanks.
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Eric Fowler | 5 Apr 21:25 2016

Problem compiling lib_ev on windows

I am porting some Linux code containing libev to windows, and have run into a mysterious compilation issue.

The problem is manifested by a syntax error (repeated hundreds of times) in ev_vars.h:

#define VARx(type,name) VAR(name, type name)

VARx(ev_tstamp, now_floor)  // <<<<<< THIS CHOKES: "Error: expected a ')' "

VAR is defined in ev.c thusly:

struct ev_loop
  {
    ev_tstamp ev_rt_now;
    #define ev_rt_now ((loop)->ev_rt_now)
    #define VAR(name,decl) decl;
      #include "ev_vars.h"
    #undef VAR
  };

The problem seems to be that VAR is of the form SYMBOL(arg1, arg2 arg1). That space between the parameters
(arg2 arg1) confuses MSVC.

It looks like another Microsoft / g++ compiler snag, but I would expect the library creators to have caught
it by now, so something else must be wrong.
Working around this is certainly possible, but others who compile on Windows must have seen it, and I want to
know if I have committed a more fundamental and grievous error in my handling of libev.

Is this error familiar to anyone?

Thanks

Wabbit

________________________________
The information in this email, and any attachments, may contain confidential information and is intended
solely for the attention and use of the named addressee(s). It must not be disclosed to any person(s)
without authorization. If you are not the intended recipient, or a person responsible for delivering it
to the intended recipient, you are not authorized to, and must not, disclose, copy, distribute, or retain
this message or any part of it. If you have received this communication in error, please notify me immediately.

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
prova1 | 5 Mar 01:25 2016

An up to date comparative Benchmark?

Hello everyone.

Has any benchmark been done recently? Everything I find is old and I 
would like to compare libev, libevent, libuv and the like.

Greetings! :)

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Arūnas Česonis | 28 Feb 17:22 2016
Picon

libev-4.22 C++ does not build without EV_SIGNAL_ENABLE

diff --git a/ev++.h b/ev++.h
index 4f0a36a..d1c84c8 100644
--- a/ev++.h
+++ b/ev++.h
 <at>  <at>  -337,10 +337,12  <at>  <at>  namespace ev {
       ev_feed_fd_event (EV_AX_ fd, revents);
     }

+#if EV_SIGNAL_ENABLE
     void feed_signal_event (int signum) throw ()
     {
       ev_feed_signal_event (EV_AX_ signum);
     }
+#endif

 #if EV_MULTIPLICITY
     struct ev_loop* EV_AX;

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
adream | 28 Feb 07:42 2016
Picon

why parents and child has to recreate the epoll set after fork

Hi,
The  EVBACKEND_EPOLL part of  libev manual  said:
           The biggest issue is fork races, however - if
            a program forks then *both* parent and child process have to
            recreate the epoll set, which can take considerable time (one
            syscall per file descriptor) and is of course hard to detect.

I want to know why?

After did some google, this site said, if the child close fds, it will lead the fds clear form the epoll set in the parents.
https://lkml.org/lkml/2007/10/27/25

But my example code show that closing fds in child wouldn't clear the parents epoll set.

So I want to know why the parents and child should has to recreate the epoll set after fork.
Thank you.

this is my example code:

#include<stdio.h>
#include<stdlib.h>
#include<unistd.h>
#include<errno.h>
#include<netdb.h>
#include<fcntl.h>
#include<string.h>
#include<sys/types.h>
#include<sys/socket.h>
#include<sys/un.h>
#include<netinet/in.h>
#include<netinet/in.h>
#include<netinet/tcp.h>
#include<arpa/inet.h>
#include<sys/epoll.h>


int StartTCPListener(const char* ip, const char* port)
{
    int server_sockfd;
    socklen_t server_len;
    struct sockaddr_in server_address;
    int flag;
    int reuse = 1;

    server_sockfd = socket(AF_INET,SOCK_STREAM,0);
    if(server_sockfd==-1) return -1;
    setsockopt(server_sockfd,SOL_SOCKET,SO_REUSEADDR,&reuse,sizeof(reuse));
    server_address.sin_family = AF_INET;
    server_address.sin_addr.s_addr = inet_addr(ip);
    server_address.sin_port = htons(atoi(port));
    server_len = sizeof(server_address);
    if( bind(server_sockfd,(struct sockaddr*)&server_address,server_len) ) return -1;
    if( listen(server_sockfd,SOMAXCONN) ) return -1;
    flag = fcntl(server_sockfd,F_GETFL);
    fcntl(server_sockfd,F_SETFL,flag|O_NONBLOCK);
    fcntl(server_sockfd, F_SETFD, FD_CLOEXEC);
    return server_sockfd;
}

int AcceptTCP(int server_fd)
{
    int client_fd;
    socklen_t client_len;
    struct sockaddr_in client_address;
    client_len = sizeof(client_address);
    int flag;

    client_fd = accept(server_fd,(struct sockaddr *)&client_address,&client_len);
    if(client_fd>0)
    {
        flag = fcntl(client_fd,F_GETFL);
        fcntl(client_fd,F_SETFL,flag|O_NONBLOCK|O_DSYNC);
        fcntl(client_fd, F_SETFD, FD_CLOEXEC);     
    }
    return client_fd;
}

static int AddToEpollSet (int efd, int fd, int events)
{
    struct epoll_event e;
    memset(&e, 0, sizeof(e));
    e.events = events;
    e.data.fd = fd;
    if (epoll_ctl(efd, EPOLL_CTL_ADD, fd, &e) == -1)
    {
        int err = errno;
        fprintf(stderr, "epoll_ctl(ADD) failed : %s\n", strerror(errno));
        return -1;
    }
    return 0;
}

int main(const int argc,const char* argv[])
{
    int cpid;
    int efd;
    int sfd = StartTCPListener(argv[1],argv[2]);
    struct epoll_event listener_evetn;
    int n;
    int cfd;
    const char *msg="Hello world!\n";

    if(sfd<0)
    {
        fprintf(stderr,"set socket listening error : %s\n",strerror(errno));
        return -1;
    }
    efd=epoll_create(8);
    if(efd<0)
    {
        fprintf(stderr,"epoll_create error : %s\n",strerror(errno));
        return -1;
    }
    if(AddToEpollSet(efd,sfd,EPOLLIN)<0)
    {
        fprintf(stderr,"add socket to epoll set error : %s\n",strerror(errno));
        return -1;
    }

    cpid=fork();
    if(cpid<0)
    {
        fprintf(stderr,"fork error : %s\n",strerror(errno));
        return -1;
    }
    if(cpid==0)
    {
        printf("child progress %d\n",getpid());
        close(sfd);
        exit(0);
    }
    waitpid(cpid,NULL,0);
    printf("%d fork %d\n",getpid(),cpid);
    n=epoll_wait(efd,&listener_evetn,1,-1);
    if(n>0)
    {
        if(listener_evetn.events & EPOLLIN)
        {
            cfd=AcceptTCP(listener_evetn.data.fd);
            if(cfd>0)
            {
                write(cfd,msg,strlen(msg));
                close(cfd);
            }
        }
    }
    close(sfd);
    close(efd);
}



_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
Ponomarenko Andrey | 26 Feb 13:27 2016
Picon

ABI report

Hello,

I've prepared ABI changes/backward binary compatibility report for the recent versions of the libev: http://abi-laboratory.pro/tracker/timeline/libev/

Hope the report will help Linux maintainers to be aware of future and past ABI changes, added/removed
binary symbols and SONAME bumps. Source code of the project is here: https://github.com/lvc/abi-tracker

Please let me know if there are some false positives/negatives in the report.

Thank you.

_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev
adream | 24 Feb 14:22 2016
Picon

question on ev_loop_fork

hi
    I thought, if I didn't call the ev_loop_fork in the child, then the watcher in child wouldn't be triggered.
    This is my code, I build the ev_loop with EVBACKEND_EPOLL and EVFLAG_NOENV flags, so there is no EVFLAG_FORKCHECK flag, then I comment the ev_loop_fork call in the child. if everything goes well, I thought the child will not trigger the timeout callback function. but actually, the output is something like this:
4980 fork 4981
time out at 4980
time out at 4981
     it means that the watchers also has been triggered in the child.




#include<ev.h>
#include<stdio.h>
#include<unistd.h>

void timeout_cb(EV_P_ ev_timer *w,int revents)
{
    printf("time out at %d\n", getpid());
    ev_break(EV_A_ EVBREAK_ONE);
}

int main()
{
    int ret;
    ev_timer timeout_watcher;

    struct ev_loop *loop = ev_default_loop(EVBACKEND_EPOLL | EVFLAG_NOENV);

    ev_timer_init(&timeout_watcher,timeout_cb,5.5,0.);
    ev_timer_start(loop,&timeout_watcher);
    ret = fork();
    if(ret>0) printf("%d fork %d\n",getpid(),ret);
    else if(ret==0)
    {
        //ev_loop_fork(EV_DEFAULT);
    }
    else return -1;
    ev_run(loop,0);
    return 0;
}
_______________________________________________
libev mailing list
libev <at> lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/libev

Gmane