> > Again, the question to answer is how to make it work better. > But if you really think that the above observation on the > dynamics of data flow is incorrect, please state the reasoning.
I gave my reasoning above. I think that the answer was already given earlier in the thread. Instead of blocking, yield. Either that, or go back to the "if the buffer is full, block" semantics. Hmm. Maybe the real answer is do the former on single processor systems and the latter on multi-processor systems? If the hearth of the matter is doing something Nagle-like for loopback connection, how about introducing a minimum time delay between wakeups of the reader (if TCP_NODELAY is not set of course). With Nagle, there is a natural delay which is proportional to the RTT. But fused connection, we could just have N times (say 20->50 times) bigger than the scheduling overhead. The would allow the read buffer to build up. It would not help the application's write side to reduce it's number of writes but the behavior would be similar to a network deployment. -r _______________________________________________ networking-discuss mailing list [email protected]
