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: RFC: Deadlock in multithreaded application when doing IO andfork.


On 02/01/2013 04:06 PM, Rich Felker wrote:
> On Fri, Feb 01, 2013 at 01:01:38PM -0800, Roland McGrath wrote:
>>> But not safe to use async-signal-unsafe functions in the child after
>>> fork. In particular, malloc is not legal after fork in a
>>> multi-threaded program, so the simplest solution would be to remove
>>> all the atfork handling for malloc.
>>
>> The issues at hand are in the atfork handlers that run in the parent.
>> There are no restrictions on what calls those can make.
> 
> I'm not claiming it's disallowed to poke with malloc in the parent.
> I'm claiming it's useless to use atfork handlers to attempt to give
> the child a consistent malloc state because the child is not allowed
> to use malloc anyway.

While that is true, we actually go to great lengths to make as much
as possible work in the child after the fork. 

Why? 

Probably because it's hard to do any useful work without malloc :-)

I seem to remember that previous POSIX specifications didn't have 
the restricting statement that says only async-signal safe functions
may be called after fork()?

The malloc atfork handlers look to be 10+ years old. Thus we likely
have applications in the wild that need malloc et. al. to continue 
working after the fork.

The test case that actually triggers this could be fixed by removing
the malloc atfork handlers.

However, it would be a regression in the supported functionality 
we have in glibc.

I'm just happy we don't have to make multithreaded fork 
async-signal safe!

Cheers,
Carlos.


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