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

[Serge Hallyn]

Quoting Steven Stewart-Gallus (sstewartgallus00 at mylangara.bc.ca):
> Hello,
> 
> I understand that LXC uses sandboxing heavily. After taking a look at
> the source I don't think that LXC uses multithreading and that it

It doesn't much *use* them, but it very heavily supports their use
using the API.  Take a look at src/tests/concurrent.c and look
at the go bindings (https://github.com/lxc/go-lxc).

> tries to accomplish any multiprocessing needs by forking instead.

Yup, we insist that a task be single-threaded when it actually
starts a container.

I can see where for sandbox use by application a sandboxing
library might want to allow use by threads, and it'd be a very
interesting thing to work on, but that is not lxc's use case.

> However, the topic I am about to bring up may be relevant if LXC
> wishes to use multithreading in the future.  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

Basically we use at_fork to make sure that any locks which may
have been held (two main ones) by another thread are not held
(later deadlocking) in the new tasks.

> what sort of functionality GLibc needs to change to make required
> functionality more async-signal-safe after a fork from a multithreaded
> program 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.  I am not
> subscribed to lxc-devel so you may want to CC me.
> 
> Thank you,
> Steven Stewart-Gallus

Thanks, Stewart.  Note that about a month ago we had been pinged by
Carlos, who I assume you are also working with?  Eric pointed out
one issue here:

https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-August/009921.html

thanks,
-serge