lkml.org 
[lkml]   [2001]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] /dev/epoll update ...

On 20-Sep-2001 Dan Kegel wrote:
> One more question: if I guess wrong initially about how many
> file descriptors I'll be monitoring with /dev/epoll, and I need
> to increase the size of the area inside /dev/epoll in the middle of
> my scan through the results, what is the proper sequence of calls?
>
> Some possibilities:
>
> 1) EP_ALLOC, and continue scanning through the results
>
> 2) EP_FREE, EP_ALLOC, EP_POLL because old results are now invalid
>
> 3) EP_FREE, EP_ALLOC, write new copies of all the old fds to /dev/epoll,
> EP_POLL, and start new scan
>
> I bet it's #3. Am I right?

I'm coding a solution that try to minimize the reallocation cost even if it's better
to preallocate the number of fds without changing it.
If you think to handle 200000 fds in your system the memory cost of the epoll
allocation is nothing compared to the file*, socket buffer, etc...




- Davide

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.161 / U:1.864 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site