Boost logo

Boost :

From: Iain K. Hanson (ikh_at_[hidden])
Date: 2005-04-27 19:34:05


On Wed, Apr 27, 2005 at 07:34:25PM +0200, Giovanni P. Deretta wrote:
> Iain K. Hanson wrote:

[snip]
>
> 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
> requirement.

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

BTW char, signed char, and unsigned char are 3 different types and only unsigned
char satisfyies the requirements for networking portably.

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.

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.

regards

/ikh


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk