On Fri, Dec 13, 2013 at 8:49 AM, sven falempin <sven.falem...@gmail.com> wrote: > Hello, > > I add a bug related to multithread, but it was just some noise. > Just to be even more sure i use evutil_make_socket_nonblocking now. > > I am now at like 12hours or more before reproducing the problem, so next > time i will probably focus on lowering the backlog number. > > (gdb) bt > #0 0x00000000004acf7c in __sys_accept () > #1 0x0000000000492ca0 in accept () > #2 0x00000000004299cb in listener_read_cb (fd=7, what=<optimized out>, > p=<optimized out>) at listener.c:396 > #3 0x0000000000427d6e in event_process_active_single_queue > (activeq=0x800867050, base=<optimized out>) at event.c:1350 > #4 event_process_active (base=<optimized out>) at event.c:1420 > #5 event_base_loop (base=0x800868300, flags=<optimized out>) at > event.c:1621 > #6 0x000000000041b0ef in main (argc=10, argv=0x7fffffffdb88) at main.cc:261 > > > My question is: > Maybe adding the error callback would help ?
I think that's a pretty good idea. 100% kernel load on accept() is often symptomatic of ENFILE or EMFILE , and the typical solution -- after raising resource limits as appropriate, and making sure you don't have a socket leak -- is to do something in response other than just closing the socket -- like closing the listener for a while, or until some sockets have closed, or disabling it, or such. -- Nick *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
