On 07/29/2010 01:37 PM, Nathan Lynch wrote: > On Thu, 2010-07-29 at 10:56 -0400, Oren Laadan wrote: >> 1) The separate fd-table between the coordinator and the feeder >> is just a convenience and can be relatively easily relaxed so >> that pthreads may be used. However, ... >> >> 2) More importantly, malloc() and printf() also occur in the >> processes and threads generated during the creation of the new >> (restored) task tree. So the same problems may occur there as >> well. Unfortunately, here we can't use glibc, in part because >> it is not even supported by glibc. >> >> Maybe a more robust way to address this is to: (1) use mmap() >> and munmap() instead of malloc() and free(), and also (2) use >> sprintf() + write() instead of printf(). >> That should make everything thread-safe. Did you notice other >> libc calls which may be problematic ? > > No, I think you covered it. The only remaining concern I have is > whether accesses to global state (like the context) are adequately > serialized, and if not, what mechanism could provide mutual exclusion > (semaphores?). That global variables (*) like the context are set once prior to the fork/clone starts, and are immutable thereafter. So I'll go ahead and clean it up. (*) except for signal handling, which I'd like to remove anyway. Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
