Re: aio_read implementaion in Squid

Provided there is a well working AIO implemenation designed for
networking I/O then there should be no major issues besides compability
and some extra memory requirements for I/O buffers (at lest one buffer
per pending read).

AIO also fits quite nicely into the eventio framework discussed and
partly implemented. <http://squid.sourceforge.net/eventio/>

However, I seriously doubt the AIO implementation quality on most
platforms for the type of I/O pattern of Squid networking. In most cases
the AIO implementation is optimized for disk I/O where it is of most use
as there is no other standard method of asyncronous disk I/O. You may
well find that the AIO implementation will use the fallback I/O method
for networking, using one thread of execution per pending I/O call,
quickly exhausting the host resources or causing quite substantial I/O
latencies depending on the actual AIO configuration.

I have also investigated the signal I/O driven model of Linux. While
looking great on the paper, this I/O model actually have quite
substantial drawbacks. Partly from poor kernel implementation (way too
many events are generated), partly from design. However, the design
issues is tolerable and once the implementation is cleaned up this I/O
model can be really cool.

--
Henrik Nordstrom
Squid Hacker
> Venkatesh wrote:
> 
> Hi All,
> 
> What are the issues if we go for aio_read() instead of read() with
> poll() other than posix compatibility?
> 
> Do you all agree with this kind of implementaion for Squid?
> 
> Any comments?
> Venkatesh