Bug 727498 highlights the need of sharing pools that may be used by more then one elements. This not being fully considered in general when dealing with pool.

Related to that, it may means that an active pool could be shared, in which case calls to set_config() will fail, and certain settings ignored. This need for sure more clarification and structure, but base on the analyses we will have to review the usage of pools so we know we keep doing the right thing. Specially for cases where pools cannot grow.

While doing this investigation, it would be nice to have the reflection on how to check the "negotiated" result of calling set_config(). As the doc says, any modification of the requested config should lead to FALSE being returned, though config shall be updated as far as possible. I supposed the intention was for the negotiator to re-read the config it tried to set and check if it should try the next propoosed pool/allocator, or if the changes are acceptable in the context.