If I understand Scott correctly, the problem still exists, if you want to use the lib in that way.
Assume an object whose serialization is something like 4K. If reading from a file, or even a TCP stream with the socket in blocking mode, then you just keep reading until you get all the data. However, for a socket in non-blocking mode, you will typically use select or poll or some other notification mechanism to be told when data is available. You will then go read as much as is currently available, and then return to other tasks until more data is ready. Let's say that data is slow, and to ready the entire 4K of data, it takes 10 different "notifications" and 10 different "read" operations.
I don't think this is that big of a problem. This is usual situation in marshaling implementation that parser/builder/marshaler class need to have completed data block. And the usual solution is to use some kind of protocol level envelope that allows detect end. So what you do is you collect you pieces in buffer and then process it altogether. This is a case whether you sending object by object or (most probably) whole I don't know ... message. In all practical cases it does not incur any significant time/space overhead (IOW buffer size, envelope and message units could be configured so it's efficient). Gennadiy