Re: StringNg review: MemBlob

On 10/19/2010 08:08 AM, Kinkie wrote:
> On Mon, Oct 18, 2010 at 7:56 PM, Alex Rousskov wrote:
>
>> Once MemBlob is committed, please consider re-integrating it with memory
>> pools. This is the biggest remaining XXX, IMO.
>
> I've checked and confirmed why MemPools integration was disabled: it's
> due to an inherent asymmetry in memAllocString/memFreeString: if
> mempools are not initialized, memAllocString will happily allocate the
> string using xcalloc. When the time comes to deallocate such strings,
> it will fail to find a pool to dealloc from and fail an assertion.
>
> The only way I can think of to cleanly resolve this is quite
> disruptive, as it means making MemPools a proper singleton obect to
> make sure they are initialized before being used: it's a complex
> project on its own which I'd list as a dependency before integrating
> MemPools back in.

What happens if you call Mem::Init() from memAllocString()? I am sure a
few things will need to be fixed (e.g., Mem::Init() should exit if
called twice), but it does not sound disruptive to me.

> IMVHO body pipelining should go through SBuf, not MemBlob, but that's
> for body pipelining to work out.

Currently, MemBlob's append-only design prevents efficient message body
pipelining. Since SBuf relies on MemBlob, SBuf inherits the same problem
(and adds more problems due to poor used area tracking). We will need to
decide whether to enhance MemBlob/SBuf to improve pipelining support or
switch to a pipeline that uses a "bunch of buffers" instead of a single
one. This is a topic for another thread though.

Cheers,

Alex.
Received on Tue Oct 19 2010 - 14:36:09 MDT