[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2cc26e40811021115h1bf711c7i2b220a92f7cf1abc@mail.gmail.com>
Date: Sun, 2 Nov 2008 20:15:57 +0100
From: "Olaf van der Spek" <olafvdspek@...il.com>
To: "Eric Dumazet" <dada1@...mosbay.com>
Cc: "Davide Libenzi" <davidel@...ilserver.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: epoll behaviour after running out of descriptors
On Sun, Nov 2, 2008 at 8:10 PM, Eric Dumazet <dada1@...mosbay.com> wrote:
> On listen queue, socket is still ready for an accept().
True, but not handy.
> Since you use edge trigered epoll, you'll only reveive new notification.
The strace shows I receive 10+.
If a return with EMFILE is indeed a no-op, I should receive only one.
> You probably had in you app a : listen(sock, 10), so after 10 notifications,
> your listen queue is full and TCP stack refuses to handle new connections.
I've got listen(l, SOMAXCONN);
IIRC SOMAXCONN is 128.
> close(newfd); /* forget this incoming connection, we dont have enough fd */
Why not keep them in the queue until you do have enough descriptors?
> Of course, if your application is multi-threaded, you might adapt (and
> eventually reserve
> one emergency fd per thread)
Sounds like a great recipe for race conditions. ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists