On Tue, Oct 19, 2010 at 4:35 PM, Alex Rousskov <[email protected]> wrote: > 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.
Tried that, using a string-pool as singleton-like initialization indicator. There are some prerequisites to be called in turn. I have not investigated further; I can investigate further if you wish. > > >> 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. Yes. Unfortunately I don't understand what is the use case you have in mind :( My original thought was to use SBuf's append/consume pair for this. Thanks again! -- /kinkie
