Re: [Libevent-users] evbuffer_add_file() file descriptor exhaustion experiment

[Azat Khuzhin <a3at.mail@xxxxxxxxx>]

On Fri, Oct 31, 2014 at 02:52:43PM +0100, Marcin Szewczyk wrote:
> Hi,
> 
> I am struggling with exhaustion of file descriptors when using
> evbuffer_add_file(). My application responds to every line of input with
> contents of a file. I don't know how to efficiently control open
> descriptors number so when input rate is high I hit the open file

Hi Marcin,

And what you want to do when you are out of fds?
(Actually you already know this - open(2) will return -1 and errno will
be installed to EMFILE)

If you are feed data from files (using open()+evbuffer_add_file()) to
client, sometimes you will be out of file descriptors because you are
doing this very quickly.

*But* I guess you could use evbuffer_file_segment*() API, it have all
you need - cleanup callback, so you could track when some of fds closed,
and since you are already could track when some of fds opened (you call
open(2)), you will have 'open file descriptors count' implementation.

Is this what you want?

P.S. evbuffer_add_file() do use evbuffer_file_segment*() API, but
without any cleanup callback and with EVBUF_FS_CLOSE_ON_FREE flag.

Cheers,
Azat.

> descriptors limit very quickly. I would like to ask how to resolve the
> problem correctly. I have seen that long time ago someone has asked a
> similar question[1], but there was no answer.
> 
> I attach a short source code to present my problem.
> 
> Ideas made up so far (excerpt from the attached source):
>     Bad ideas:
>     1. Depending on bytes count in the output evbuffer would be 
>        troublesome if the sent file changes between 
>        evbuffer_add_file() calls -- it would require a list of last 
>        N file sizes to check if evbuffer size is below the sum of N-K 
>        sizes (N - high water, N-K - low water).
>     2. Checking fd number returned from open() wouldn't be enough
>        because after sending contents associated with the oldest call 
>        to evbuffer_add_file() the fd number is freed and the next 
>        call to open() returns a low number even though descriptors 
>        with higher numbers are still in use.
>     3. Iterating through file descriptors to check their states seems 
>        inefficient.
>     4. Listing files from /proc/self/fd seems inefficient.
>     5. One could implement a rate limit on requests but it's a quirk.  
>        There is no guarantee of the output rate.
>     6. ???
>     
>     Possibly useful ideas:
>     1. extend evbuffer_cb_info to have open file descriptors count
>     2. implement evbuffer descriptor closed callback
>     3. implement a function to check evbuffer open descriptors count
>     4. ???
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.