On Fri, Dec 13, 2013 at 8:49 AM, sven falempin <sven.falempin@xxxxxxxxx> wrote:I think that's a pretty good idea.
> 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 ?
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 majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users  Âin the body.