On 07/27/2018 06:43 AM, Florian Weimer wrote:
On 07/26/2018 06:03 PM, Jason L Tibbitts III wrote:
>>>>>> "FW" == Florian Weimer <fweimer(a)redhat.com>
writes:
>
> FW> I would like to request a change of the Packaging Guidelines,
> FW> advising packagers not to interpose malloc.
>
> How strong of a restriction are you looking for? This sort of
> feels like something which would at the strongest be a "SHOULD NOT"
> but maybe you're looking for an absolute ban.
An absolute ban strikes me as overly broad. However, especially for
shared objects (such as libruby), the implications should be clear:
it is easy to LD_PRELOAD a different malloc, but if the library is
linked against glibc malloc, jemalloc, and then you want to preload
tcmalloc because it helps with your workload, you might run into
problems (and if it's just excessive use of TLS data, most of it
unused).
Agreed.
> Some maintainers may find it difficult to comply with an
absolute
> ban if the relevant software doesn't make it easy to change the
> allocator.
Sure, this is why I mentioned APR pools and Boehm GC—if the APIs a
different, then we obviously can't require porting to system malloc.
If upstream bundles a custom malloc, especially one of the well-known
ones separately packaged in Fedora, some work is required anyway
because the bundled version cannot be installed in a system-wide
location, and RPM provides for it must be suppressed. (See the
upstream varnish packages for an example of an accidental system-wide
jemalloc installation.)
Right, if the relevant software doesn't make it easy to change the
allocator then that's OK, but what we ship must be made safe to ship.
--
Cheers,
Carlos.