----- Original Message -----
From: "Henrik Nordstrom" <hno@squid-cache.org>
>
> But there is other complications as well even if we stay HTTP/1.0.
>
Ok. I guess that this means that there still is a lot of room for further
research left in this area, and we just aren't there yet for real world
applications. Maybe I should just stop reading those research papers...
>
> It is my opinion that there is many better ways of optimizing proxy
> class I/O without resorting to kernel level "splicing". For example
> it would be very interesting to see a I/O mechanism not involving
> copying of data on each read/write combined with a sane event
> notification. This would accomplish the same goal with fully
> preserved semantics and only marginally increased CPU load compared
> to kernel level "splicing".
>
Well at least we seem to agree on the fact that the context switches and
data copy caused by application-level transfers results in performance loss,
and that this could be addressed.
;)
>
> (AIO has reasonable I/O primitives but lacks in notification,
>
Well as far as I can tell, asynchronously notifying the I/O completion in
AIO is accomplished by sending signals, and an application may request that
a SIGIO signal be delivered when the I/O operation is complete. If several
requests have been issued, the application can poll the status of the
requests to determine which ones have actually completed. From your message,
I gather that this is not sufficient ? I vaguely seem to remember some
issues (regarding the reliable delivery ?) when using signals in combination
with threads.
Sincerely,
John Smith
Received on Wed Sep 10 2003 - 21:22:27 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:41 MST