Re: [Libevent-users] out-of-order writes in an evbuffer

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, May 21, 2013 at 4:58 PM, Adrian Chadd <adrian@xxxxxxxxxxxxxxx> wrote:
> You can do a couple of things:
>
> * you can hack up the serialisation and buffering stuff so yes, it
> injects that length value into an already-queued buffer;

I think some kind of hack like this is what you're going to have to
do, if you truly can't calculate the length in advance: reserve the
four bytes, fill them with 0s, but keep a pointer to them that you
populate later.

This is *not allowed* according to the current evbuffer
specifications, though it should likely work in practice. You'll need
to skim the evbuffer code to see what can resize or remove an existing
chunk.  I can't promise that this will work in all scenarios, or that
it will work with future versions of Libevent: you'll need to make
sure that your tests can handle checking all the assumptions you're
depending on.

If you can come up with any interface improvements to Libevent that
might help with this, that would totally be another viable approach to
take.  There is currently a "pinning" feature internally in evbuffers
that can be used to tell Libevent not to reallocate or free a given
chunk until it is unpinned -- but that feature is only designed for
making iocp function correctly, and probably needs more work before it
can be a general mechanism for applications to use.

  You'll also need to do something to keep the four 0 bytes from
getting flushed to the network before you replace them with the real
values.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.