On 06/21/2011 06:47 AM, Amos Jeffries wrote:
> Moving the cache_peer pool to the peer init area has brought to light
> the problem of this pool init function not being safe for repeated
> calls. (bug 3245)
>
> We had some discussion when the opposite of this came up about strings.
>
> Since we have not really settled on whether to make MemPools an
> on-first-demand system I think its time to make some kind of TODO plan now.
>
>
> Do we want to eventually make memory initialization happen on first use?
> In which case I commit this patch now as one small step towards that.
>
>
> Or do we want to set an absolute init order and fail loudly if
> components are initialized in the wrong order?
> In which case I revert the peerSelectInit() changes.
From the caller/API perspective, memory routines should "work" whenever
they are called, and no strict initialization order can be guaranteed.
Whether every memory pool is initialized on the first use or just safely
skipped until it is ready to be initialized later is a separate
question, internal to the pool design.
Thus, I do not see a problem with this patch. Please commit if it helps.
Thank you,
Alex.
Received on Tue Jun 21 2011 - 15:22:59 MDT
This archive was generated by hypermail 2.2.0 : Tue Jun 21 2011 - 12:00:04 MDT