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

2014-09-05 Thread Alexander E. Patrakov
31.08.2014 09:31, Steven Stewart-Gallus 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

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

2014-09-05 Thread Florian Weimer
On 09/03/2014 08:45 PM, Lennart Poettering wrote: On Sun, 31.08.14 03:31, Steven Stewart-Gallus (sstewartgallu...@mylangara.bc.ca) wrote: 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

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

2014-09-03 Thread Lennart Poettering
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

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

2014-08-30 Thread Steven Stewart-Gallus
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