Boost logo

Boost :

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
> discussion.

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
>>vector io.
>>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, gregod at, cpdaniel at, john at