While talking about pain points there is a very large one. In short pthreads break fork().
At least according to the open group after fork (when more than one pthread is active) and by extension clone(CLONE_NEW...) it is only safe to call async-signal-safe functions. The rationale being that some other thread might have possibly held a lock during fork. Which means it becomes extraordinarily difficult to safely set up and read /proc/mounts etc, etc. Because malloc and huge portions of supporting code are now verbotten. Several of the namespaces require a non-trivial amount of set-up work from within. The mount namespace requires calling mount, umount, and pivot_root. The network namespace requires making netlink calls over sockets. The work arounds involving multi-process synchronization and setns after fork are quite ugly. It would be nice if at least malloc and C++ new were safe (and documented as safe) after fork in a pthread environment. That would go a long ways to allowing running interesting set up code without having to jump through hoops. Eric _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
