This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Increase fork signal safety for single-threaded processes [BZ #19703]
- From: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 11 May 2016 16:59:34 -0300
- Subject: Re: [PATCH] Increase fork signal safety for single-threaded processes [BZ #19703]
- Authentication-results: sourceware.org; auth=none
- References: <20160511134121 dot CDFB841B3C727 at oldenburg dot str dot redhat dot com>
Florian Weimer <email@example.com> writes:
> This provides a band-aid and addresses the scenario where fork is
> called from a signal handler while the process is in the malloc
> subsystem (or has acquired the libio list lock). It does not
> address the general issue of async-signal-safety of fork;
> multi-threaded processes are not covered, and some glibc
> subsystems have fork handlers which are not async-signal-safe.
> 2016-05-11 Florian Weimer <firstname.lastname@example.org>
> [BZ #19703]
> Partially async-signal-safe fork for single-threaded processes.
> * sysdeps/nptl/fork.c (__libc_fork): Introduce multiple_threads
> variable. Do not acquire and reset/release malloc and libio locks
> in single-threaded processes.
> * malloc/tst-mallocfork2.c: New file.
Do you have plans to remove malloc/tst-mallocfork?
> diff --git a/malloc/Makefile b/malloc/Makefile
> index 3283f4f..fa1730e 100644
> + sigusr1_sender_pid = fork ();
> + if (sigusr1_sender_pid == 0)
> + signal_sender (SIGUSR1, false);
> + pid_t sigusr2_sender_pid = fork ();
> + if (sigusr2_sender_pid == 0)
> + signal_sender (SIGUSR2, true);
I suggest to fork the SIGUSR2 sender first.
Sometimes the SIGUSR1 sender floods the parent to the point it takes seconds
to fork the second sender.