----- Original Message ----- From: "Henrik Nordstrom" <[EMAIL PROTECTED]>
> > 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
