This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should malloc-related functions be weak?

On 08/01/2016 01:04 PM, Pedro Alves wrote:

On 08/01/2016 11:39 AM, Florian Weimer wrote:

On 08/01/2016 12:25 PM, Pedro Alves wrote:



Are these other symbols meant be overridden?


These symbols (__malloc_fork_lock_parent etc.) are not supposed to be
overridden, they are entirely internal to glibc and its malloc
implementation.  If the glibc malloc is interposed, these functions
should not do anything.


Hmm, doesn't an interposing malloc need to worry about the same
scenarios these hooks were invented for?
Yes and no. For multi-threaded programs, preserving heap consistency across fork is optional. glibc malloc provides a working malloc after fork as an extension over POSIX. 


Say I copy glibc malloc to my project, and tweak it somehow for my
workloads.  How can I make my copy work just as correctly as the
builtin one?
You can't. You will have to change the algorithm, use the existing fork handlers framework, or drop the POSIX extension. 

Florian
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]