Quoting Steven Stewart-Gallus (sstewartgallu...@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 _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
