Re: [ST-devel] Re: autoconf and libst

[Lev W. <vl...@ne...>]

Gene wrote:

> Lev Walkin wrote:
> 
>>>>poll() is faster than select() - is this wrong?
>>>>
>>>>
>>>In addition to the other analysis offered of relative speed, select has
>>>the feature that multiple threads waiting for the same fd don't change
>>>the system call.  With poll, each waiting thread has its own pollfd even
>>>if all of the fds are the same.  So the right choice (poll vs. select)
>>>depends on not only the total number of fds but also their expected use.
>>>
>>Again: if we want to make st even faster (20% to TIMES faster), we should
>>
>>consider build an independent scheme, and implement a modern techniques,
>>like kqueue() or /dev/poll. We will give the ST the speed and the
>>scalability of state-driven kqueue() (or /dev/poll)'based applications.
>>
>>It will be a really huge improvement, not even comparable with omission
>>of a system call one time per thread life.
>>
>>
> 
> Oh no, not this poll vs. /dev/poll vs. kqueue discussion again!!! :)
> 
> Why do you think that optimizing the idle state would bring you a
> "huge improvement"?


Because I've read a number of papers related the impact of this
technologies to a _common_ types of services: http daemons, et
cetera. Everybody involved in this seems to agree that converting
a network events (NIC interrupts) into a states, than converting
these states back into events (poll()/select() then do the
event-like processing) is not a very good idea with the number
of sockets greater than ONE. But why do YOU think that going
with an old good poll instead of modern event-oriented interfaces
is benefit?

-- 
Lev Walkin
vl...@ne...