On Sun, 31.08.14 03:31, Steven Stewart-Gallus (sstewartgallu...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel