Serge Hallyn <serge.hal...@ubuntu.com> writes: > Quoting Eric W. Biederman (ebied...@xmission.com): >> >> Serge Hallyn <serge.hal...@ubuntu.com> writes: >> > Quoting Carlos O'Donell (car...@redhat.com): >> >> There was a complaint a while back from someone working >> >> on containers about glibc PID caching. I recently received >> >> another request to provide userspace with a way to reset >> >> any PID or TID caches to make clone-based sandboxing easier >> >> (CLONE_NEWPID). >> >> >> >> How did lxc workaround the PID cache in glibc? What APIs >> >> could glibc provide to help the implementation of containers?
>> That said clone(3) is a cumbersome API to use when you don't want to >> share the same address space (it sucks to have to allocate an extra >> stack just to call fork(2)), and that probably gets people resorting to >> calling syscall(SYS_clone,...) and then having pid problems. > So, the long and short of it is, we're all happy with what we've got? > > Or did I as usual misread your main point? clone(3) sucks to use for creating namespaces. Having to create a stack when you don't pass CLONE_MM adds all sorts of unnecessary complications. I suspect in some cases that gets people to call syscall(SYS_clone) and thus run into the pid caching of glibc. Eric _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel