From: Giovanni P. Deretta (lordshoo_at_[hidden])
Date: 2005-04-27 20:29:33
Iain K. Hanson wrote:
>>Yes, the buffer is absolutely necessary, but does not need to be
>>contiguous in memory: it can be composed from smaller buffers.
>>This smaller buffers can be used by a streambuffer. When the
>>streambuffer detects that the buffer is full, it does not immediatelly
>>write it out, it simply queues it in a buffer vector and gets a new
>>empty buffer. When the size of the buffer vector reaches an ideal size
>>(MSS or MTU), it is written using vectored io (writev or writemsg).
>>This way the streambuffer user does not need to be aware of buffer size
> Hi Giovanni, Yes i am aware of scatter / gather but I was simplifying in order
> to get my point across. However, even in scatter / gather each individual
> buffer must be contigous. The idea of using a concept is that there can be
Of course the single buffers are contiguous. The point here is that you
don't need to flush every time a single buffer is full. You keep
filling buffers until you explicitly flush the stream (std::endl).
> more that one class that implements the concept so not just vectors but
> also boost::array and unsigned char , and there may be other containers.
I do not see how this is related with the problem. Using multiple
buffers is an implementation detail that let the user be oblivious of
transfer size optimizations.
> BTW char, signed char, and unsigned char are 3 different types and only unsigned
> char satisfyies the requirements for networking portably.
Right, I didn't think of this.
> I'm not at all sure that you can absolve the user from buffer size concerns
> but I also don't know that your wrong. I don't personally have a strong
> interest in an iostream interface or rather III have not until this recent
Neither do I, but i think that once you have working underlying
networing framework framework, it will not be hard to fit iostreams on
top of it.
> I always assumed that the critisisims of an iostream interface for sockets
> were valid. As I have thought about it more I am inclined more to the view
> that the overhead could be constant and that is interesting.
>>A simmetric aproach can be used for reading.
>>This is expecially useful if you read data from disk and want to write
>>it out after appending a small header, if you don't want to copy header
>>and file data on a single buffer you have to do two writes OR you use
>>This boils down to one single rule: when reading read as much as
>>possible (i.e. untill we would block), when writing write as much as
>>possible. If user code wants to see writing and reading as small
>>operations they are free to do so.
>>This rule is also usefull when using edge trigered readiness
>>notification APIs (epoll and kqueue in edge trigered mode).
> Agreed. But I have great difficulty in understanding why anyone would want
> to do edge triggered epoll / kqueue / dev/poll.
Well why not, it might actually simplify some code.
-- Giovanni P. Deretta
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk