Comment 1 for bug 555873

Server is not really reading in the first iteration as much as JARDIN_DEFAULT_RECV_BUFFER_SIZE. The buffer may get filled only partially, and the user-provided callback gets called; then more bytes arrive, and user-provided callback gets called again. Note that this issue is only applicable to STREAM connections (TCP if INET), as with DGRAM the whole datagram arrives as a whole and user-provided callback is only called once.

If I understand the issue properly, you suggest to enable some way to wait & read more bytes inside the user-enabled callback right? If so, this is not really recommended, as you would be blocking the whole thread of execution while waiting for more data to come.

If waiting for a loong stream of bytes to arrive, it should be a task of the programmer to decide what to do while the whole stream didn't arrive. For example, if the stream of bytes is a 8GB DVD image arriving through TCP, the user-defined callback should never block & wait for the arrival of the whole chunk. In this case, the user-provided callback should receive each stream chunk in the recv buffer, and append the received bytes to a temporary file somewhere, until the whole stream of bytes arrives and the user-defined callback can properly generate the received file with all its contents.

If thinking in smaller streams of bytes, the temporary store with the already received stream chunks may be stored in heap memory instead of disk.

My 2 cents.