Re: [boost] [review] Asio formal review.

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-23 04:17:39

Hi Rene,

--- Rene Rivera <grafik.list_at_[hidden]> wrote:
> Because this is a concern for everyone. I might be the only
> person currently asking for this, but I won't be the last. I
> am raising these issues for the general benefit of the Boost
> review. Someone has to think about how the library addresses
> the full spectrum of needs, even if it wasn't originally
> designed for it. The best designed libraries can accommodate
> unknown uses. But if your position is that since it doesn't
> allow for a certain, to my POV, reasonable modularity standard
> to just "hack" around it, I'd have to say that my vote went
> from "no but I would consider changing it". To a: "vehement
> no". I don't want to see libraries in Boost that fail some
> basic abstraction uses.

I would have thought that basic abstraction would involve hiding
the implementation, not exposing it.

As I understand it, your initial "no" was based on two things:
documentation deficiencies (fair enough) and the cost of memory
allocations. I have already demonstrated an approach for
customising memory allocation that doesn't alter the overall
design.

The issue on which you are now focusing is that there is no
public interface that allows you to select different
combinations of platform-specific components. Firstly, yes, this
could be done, without any change to the current public
interface. As I have said elsewhere, over time I may allow these
components to evolve into a secondary public interface that is
explicitly noted as having restricted portability.

However, this requirement is, from my point of view, very
specialised and unlikely to be widely applicable. Furthermore,
if tomorrow I find an improved way of using epoll that
necessitates a rework of the epoll_reactor interface, then I
would not hesitate to do so. Exposing these platform-specific
internals may hinder my ability to optimise that which is to me
the most important - the portable interface.

If we have a fundamental disagreement, it would be with regard
to the "abstraction line" that you mentioned in an earlier post.
I appreciate that the level I have set it at may be too high for
your purposes. I would ask that you appreciate that asio was
always intended to be portable, and I have chosen to set the
public interface at the lowest possible portable level. What you
are asking for is a public interface that exposes non-portable
constructs; this is clearly at variance with my design goals.

> But to make the selection of which method, epoll, select,
> etc., to use more salient to you personally, I have a simple
> question for you if Asio is accepted into Boost:
> 
> How do you expect to write tests for your library that cover
> *all* the various methods supported in one platform?

By doing what Caleb Epstein suggested and having a different
macro passed when building each set of tests.

I note that this is how Boost.Threads, for example,
differentiates between the native Windows threads and pthreads
variants. Is this also insufficient for your needs?

Cheers,
Chris