From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-01-03 07:17:40
--- "Giovanni P. Deretta" <gpderetta_at_[hidden]> wrote:
> Sometimes you need to make some hard decision. There are any
> real-life protocol/platform that need shared state? If yes,
> than member functions is fine.
An example might be an operating system where the I/O is
implemented by a separate process, and communication with this
process takes place over some sort of IPC channel. Symbian is an
example of an operating system that uses this approach. I want
asio's public interface to support an implementation on systems
that use this mechanism.
> If not, or only some theoretical obscure protocol needs it, it
> should not impact the generic interface. For those
> obscure/rarely used protocol/platforms a hidden singleton
> could be used.
Symbian, as it happens, doesn't support static or global data,
so singletons are out :)
> Hum, nice, but if you want to forward a buffer another thread, for
> example, you want to forward the complete type (to preserve the
> counter and the acquire()/release() infrastructure).
Yep, this is already possible since the caller's Mutable_Buffers
(or Const_Buffers) type is preserved down into the
> I think that it should be possible to implement some streams
> that in addition to generic buffer object can accept
> specialized per stream buffer types and guarantee special
> treatment for them. For example if write() is called for
> inprocess shared memory stream, will copy the buffer if a
> generic buffer is passed, but will give special treatment if a
> special shared buffer is passed.
> In the end this boils down to passing the exact buffer type to
> the lower levels of asio implementation.
Which I do already :)
I think special cases (such as aligned or shared-memory buffers)
could be handled by implementation overloads (note: not function
overloads in the public interface) based on the type of
Mutable_Buffers::value_type or Const_Buffers::value_type.
That way individual streams can be optimised for specific buffer
types without propagating additional overloads back through to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk