Re: About user-level connection tracking mechanism: uselect()

From: Muthukumar <kmuthu_gct@dont-contact.us>
Date: Wed, 25 Feb 2004 16:11:17 +0530

Subject: Re: About user-level connection tracking mechanism: uselect()

> On Wed, 25 Feb 2004, Xia Hongtao wrote:
>
> > Had anyone heard about uselect()? uselect() is also an interface
> > for web applications to improve the performance like epoll().It provide
> > a user-level connection state tracking mechanism. Kernel and web
> > applications share a piece of memory.There are some fd_sets in this
> > shared memory.Each time the socket is ready to be read or write, the
> > relative bit in shared memory will be set a flag.Most work of uselect()
> > is just check these shared memory, without syscall and context switch,
> > without fd_set copy.When there is no ready sockets,uselect() will block
> > until any of them ready.
>
> I have not heard of it before. Sounds interesting. Where can I find more
> information about uselect?

uselect:

http://www.research.ibm.com/compsci/spotlight/web/papers.html
"Kernel Support for Faster Web Proxies,"
Marcel Rosu, Daniela Rosu, Proceedings of the 2003 USENIX Annual Technical Conference (USENIX 2003)

Paper
http://pollux.usc.edu/~cs558/papers/
http://www.usenix.org/events/usenix03/tech/rosu.html

>
> Has there been any studies in how uselect positions itself in relation to
> epoll/kpoll when the number of filedescriptors grows?
>
> > The main problem to use this interface at squid-2.5 is: I do not know,
> > in the original comm_select() loop, how many kinds of fd need to be
> > checked by select()? Currently I see these: filesystem fds(for log
> > files), TCP sockets,UDP sockets,pipes(for aio). My uselect currently can

Regards,
Muthukumar.
Received on Wed Feb 25 2004 - 03:41:19 MST

This archive was generated by hypermail pre-2.1.9 : Mon Mar 01 2004 - 12:00:04 MST