On Tue, May 21, 2013 at 4:58 PM, Adrian Chadd <[email protected]> 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 [email protected] with unsubscribe libevent-users in the body.
