tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: using of fork() in multithreaded application
>> I've fixed various issues in libc to make fork-without-exec
>> reasonable reliable for many use cases. malloc certainly was one of
>> them.
Does this still belong on tech-kern? tech-userlevel looks more
suitable to me. I'm copying this there and setting a Reply-To:;
override as you feel appropriate.
> That reminds me... (sorry if hijacking the thread).
> When a user-supplied malloc is used (dmalloc &c, or program's own
> malloc like e.g. in inferno-os), they do not override jemalloc fork
> hooks as that's not part of malloc "API contract" so to say.
> jemalloc hooks are run on fork with unitialized jemalloc internals.
> What is the right corse of action here?
I'd say the right course of action depends on whether you think
replacing malloc-and-friends is a thing you want to support. I'm not
sure what I think on that point.
If not, this is no different from providing your own copy of any other
libc thing: unsupported and entirely at your own risk. There is
nothing to do in this case except, possibly, document the risk.
But if so, then this needs to work. This seems to me like a use case
for weak references. Something like
extern void hook_real(void) __attribute__((__weak__));
void hook(void)
{
if (&hook_real) hook1real();
}
Since shared objects tend to be all-or-nothing (that is, they don't
support bringing only some of libc into the link), you probably would
also need a way to tell whether the rest of jemalloc has been
initialized, along the lines of
extern void hook_real(void) __attribute__((__weak__));
extern void didinit __attribute__((__weak__));
void hook(void)
{
if (&didinit && didinit) hook_real();
}
But if you want any replacement malloc() the program provides to be
used by other libc things that call malloc internally, especially if
the free is handled by the caller, you've got a bigger problem than
just fork hooks on your hands. (Something like getaddrinfo() is
relatively easy, because it has its own free routine, freeaddrinfo().
asprintf() is a harder case, because freeing is up to the caller.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index