Hi there, >> - Call the fork syscall directly via syscall(__NR_fork) >> Since lxc-attach is single-threaded anyway, the things glibc >> does > > lxc-attach isn't but at some point we'll want attach in the API, and > that is not single-threaded.
Now that I think about it, we do fork() in the very beginning anyway in order to make user namespaces work, so threading should be properly taken care of at that point. So when the pthread_atfork() handlers are called then, no deadlocks will occur and all the nss stuff should be cleaned up. The clone in the subprocess should then be unproblematic. Nevertheless, I've just played around with CLONE_PARENT in a simple test program and it really has the advantage that we don't clutter up the process list with too many attach processes, so I think clone is definitely the better option than a direct syscall. (Also, we have lxc_clone ready to use.) >> My suggestion would be to use clone() and to use that occasion to >> simplify the synchronization logic between all of those processes by >> using CLONE_PARENT. If I can get an agreement on this, I'll >> implement >> this, but I wanted to hear some thoughts in advance. > > Agreed. Ok, thanks, I'll prepare a patch then. -- Christian ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
