Re: [boost] asio formal review - polymorphism and impl re-use

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-28 21:38:21

Christopher Kohlhoff wrote:
> Hi Darryl,
>>Christopher Kohlhoff wrote:
>>
>>>For stream-oriented I/O, this separation is presented in the
>>>form of the Stream concept. This concept is implemented by
>>>stream_socket, ssl::stream, buffered_read_stream and so on. It
>>>would be implemented by a hypothetical pipe class.
>>
>>Precisely. Why write it/maintain it again?
> 
> 
> Well... because although the interface might be the same the
> implementation is different.

But in many cases it isn't. That was my point.

>>What do you mean by "default" - is the default selectable at
>>design/implementation or compilation time?
> 
> By "default" I mean that the interface should be designed to use
> compile time polymorphism with concepts. Runtime polymorphism
> can be introduced, should the developer choose, through a
> wrapper.

Ok.

>>>This adds up
>>>considerably if there are many layers of runtime
>>>polymorphism involved.
>>
>>Can we cut the re-education program for java programmers :-)
>>out of this and deal with the use case constructively, or
>>would you prefer to ignore it?
> 
> My design choice is based on experience in developing real-world
> high-performance networking applications that are often CPU
> bound.
> 
> A previous system I worked on made extensive use of runtime
> polymorphism via the ACE_Streams abstraction, where passing data
> through each layer involves a virtual function call.

I don't recall suggesting building ACE. If anyone had I would have 
screamed loudly. I didn't ask for a traditional OO layered polymorphic 
monster - I just suggested that it was such a common use case to want to 
read/write to anything that supported read/write concepts that this 
should be supported. It isn't exactly unprecedented.

> Since
> configuration of the individual layers did not need to occur at
> runtime, this runtime polymorphism was unnecessary. Removing it
> markedly improved performance.

Yep. Sounds familiar.

>>responding and gmane being my only interface at the time I
>>hadn't seen Caleb's results when I posted).
> 
> I do not believe that particular test is representative of

Ok. Lets leave the optimization for a separate discussion based on tests 
etc.

>>You are now expressing concern about virtual function overhead
> 
> Double indirection is not the only cost of runtime polymorphism,
[snip others]
> Do I have the benchmarks on hand to support this? No, but I have
> done these tests in the past. Working on high performance
> systems has taught me that runtime polymorphism has very real
> costs, and so in general should not be introduced unless runtime
> variation of behaviour is required. The design of asio reflects
> this experience.

I don't disagree with your concerns here, though it seems from my 
perspective that runtime polymorphism is being singled out as the root 
of all evil while other impl details can be at least as significant. 
Note I am only asking for runtime polymorphism to the extent that it is 
needed to support basic operations (read/write) not for some monstrous 
framework. My experience in memory + CPU constrained high performance 
systems using ACE led me to delete it and replace it with an in-house 
lib with rather selective (like 1) use of runtime polymorphism. YMMV. 
I'm done.

>>>>Short of placing a wrapper around asio to make it more
>>
>>^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yes to the following - but there
>>is an aspect of code re-use that it doesn't address.
> 
> 
> Which aspect would this be?

I meant wrapping N identical impls in a polymorphic wrapper to make them 
interchangeable didn't improve code re-use, thats all.

>>>stream_socket and ssl::stream. For example, both work
>>>equally well with free
>>
>>template !
> 
> 
> I guess this means that you like templates about as much as I
> like virtual functions. :)

You must be kidding. I've been writing code that VC6 can't compile since 
VC6 was released :-). C++ has a lot of features - I try to use them 
appropriately. The "template!" was in the context of my concern that I 
didn't want to have to template every piece of code that did any 
reading/writing using the lib - a template function doesn't help in that.

>>I
>>would expect many systems would be able to share a lot of
>>implementation across different stream-like file/socket/device
>>interfaces at least.
> 
> I don't think there would be as much sharing as you might think

I'm only basing this on my experience - note I'm not expecting a huge 
difference in code size etc - I'm more interested in reliability and
maintainability.

> And even in cases where there is some sharing, the common
> functionality can be extracted into a function or class to be
> called from each place, so I don't see how this design
> necessarily leads to bloat.

Ok. Bloat wasn't fair - its not a huge amount of code, and the code can 
be extracted as you say. In one of my other posts I suggest doing that 
by making lower level policy/concept composition available for library 
extension etc.

> Fundamentally, asio's public
> interface cannot assume sharing, since that assumption is
> already known to be incorrect.

Yes - thats where you need runtime polymorphism :-)

If we can step back from the technique a little and take a look at 
usage, what I would like to see is some object that provides enough of 
the interface to allow stream read/write independent of the underlying 
stream. I would like a user that only required stream read to be able to 
use a read only stream such as the read end of a pipe. I would like that 
checking to occur at compile time. Similarly for write. While it is 
always possible to wrap a number of underlying objects with similar 
interfaces to introduce polymorphism, these conceptual base classes 
can't be injected as easily. This crosses over into the area of service 
composition as discussed in my reply re portability (and a little in 
demuxer). It would probably be more productive to let this specific 
thread die and concentrate on the portability one.

Regards
Darryl Green.