Re: [cpp-netlib-devel] iovec-like async_connection::write implementation

[Dean M. B. <mik...@gm...>]

On Wed, Jan 12, 2011 at 12:24 PM, Oleg Malashenko
<ole...@gm...> wrote:
> Hello, Dean,
>
> Here is my implementation of async_connection::write_vec(). Before any
> pull requests I want you to check it to see if you like the idea.
>
> First of all, current write_impl() introduces race on user data. If
> execution flow falls in one of conditions when we need to wait for
> headers being sent than we schedule an operation and return control to
> user _without_ copying the data. The actual copying will occur after
> continue_write().
>

Hmmm... So the current implementation has a bug? I don't see how the
patch addresses that.

> Being not hardcore-templating-guru I don't know how to make specific
> write() overload with ConstBufferSequence model as a first argument
> (because it overlaps with <Range, Callback>) so I introduced write_vec
> interface.
>

That should be the reverse, you can use SFINAE to choose which
implementation to take. Just enable the <Range,Callback> version if
the Range is a Boost.Range type, enable your implementation if the
parameter is a Boost.Asio buffer sequence. Later on we can add a lot
more overloads on the user-facing interface.

Although there is no way (yet) to do concept-based dispatch, SFINAE on
specific template instances (using special metafunctions) is the best
way to achieve it.

> BTW, I think it is a good idea to explicitly specify that write() makes
> a copy of supplied data and rename it to write_copy() (see
> to_lower_copy, to_upper_copy, etc. in boost::algorithm)
>

Or, just document the behavior. ;)

> To maximise core reuse, write_impl now only prepares buffers and passes
> them to write_vec_impl.
>
> Tested both write and write_vec on 'master' with valgrind on
> linux/amd64: no memory leaks, no memory corruption.
>
> Patch provided applies cleanly to master and 0.9-devel.
>

Cool, please send in a pull request so that I can merge -- please send
two, one for 0.8-devel and 0.9-devel -- so that I can package up a
beta for 0.9, and release 0.8.1 later today.

Thanks Oleg and I look forward to the pull requests!

-- 
Dean Michael Berris
about.me/deanberris