This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Increase fork signal safety for single-threaded processes [BZ #19703]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Thu, 12 May 2016 09:06:51 +0200
- 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> <87mvnwv00p dot fsf at totoro dot br dot ibm dot com>
On 05/11/2016 09:59 PM, Tulio Magno Quites Machado Filho wrote:
Florian Weimer <fweimer@redhat.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 <fweimer@redhat.com>
[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?
No, I would just change exit to _exit there.
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.
Interesting. I have made the change locally, as you suggested.
Any comments on the change to the fork implementation?
Thanks,
Florian