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

======= 2004-02-25 11:07:00 you wroted :=======

>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?
>
>Has there been any studies in how uselect positions itself in relation to
>epoll/kpoll when the number of filedescriptors grows?

Muthukumar's URL is enough.

>> 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
>> check state of sockets, and can be awaked by aio(thanks the help from
>> Henrik).The next step I want to get rid of filesystem fds. Did I omit
>> some ? Dose aio handle I/O of swap file ?
>
>For filesystem fds you should just indicate readiness immediately. The
>only reason why these appears in comm_select() in Squid is to break the
>call stack.
>
>> There are two way to handle filesystem fds:
>>
>> 1.Use aio to write log files,the main thread only handle network I/O(The
>> squid-2.2 originally worked in this way).I think this will be the better
>> method.Because if squid worked in this way, I need not do anything. :)
>
>We are lazy and the performance difference is negliable as these are just
>relatively low speed append writes which basically never blocks.

>
>> 2.Always return ready for filesystem fds. When commSetSelect() be called
>> to check the fs fds, I put them in another fd tables. Each time
>> uselect() returns, it OR the result fd_set and that fd table.
>
>This is how select() and poll() operates, and is what is expected by
>Squid.

OK, I had finished it yesterday. I had modified diskHandleRead() and diskHandleWrite()
in the disk.c. When they call commSetSelect(), I just set the relative bit in shared
memory to represent the fd is ready.

But did diskHandleRead() and diskHandleWrite() enough? Dose there exist other functions called
commSetSelect() to check a filesystem fd ? That is one of the most important questions I
want to know. The other question is that did I omited other kinds of fds? Currently I just
focused on fs fds & pipe & socket.

>Regards
>Henrik

= = = = = = = = = = = = = = = = = = = =
Best Regards
 
                                 
　　　　　　　　Xia Hongtao
　　　　　　　　htxia@wtwh.com.cn
　　　　　　　　　　2004-02-26
                        
Received on Wed Feb 25 2004 - 19:07:47 MST