[systemd-devel] You are invited to give your thoughts on some async-signal-safety issues.

[Lennart Poettering]

On Sun, 31.08.14 03:31, Steven Stewart-Gallus (sstewartgallus00 at mylangara.bc.ca) wrote:

> Hello,
> 
> I understand that systemd uses sandboxing and multithreading.  After a
> fork, many things are messed up so it's only practical to use
> async-signal-safe functions after a fork from a threaded program.  If
> you have ideas on what sort of functionality GLibc needs to change to
> make systemd more async-signal-safe after a fork you are invited to
> give your thoughts on the GLibc mailing list in the thread at
> https://sourceware.org/ml/libc-help/2014-08/msg00039.html.

All our APIs contain checks that you cannot continue reuse contexts
you create with them after a fork(). If you try the functions will
return ESRCH.

I don't think that the glibc can change anything about the fact that
you have to exec() after a fork(). It's how these things work on
Unix. And one has to live with this, and make the best of it. And we
try to by returning explicit errors.

Lennart

-- 
Lennart Poettering, Red Hat