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: [PATCH] Increase fork signal safety for single-threaded processes [BZ #19703]


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?

> 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.

-- 
Tulio Magno


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