Re: user-cr thread safety

[Nathan Lynch <nathanl-V7BBcbaFuwjMbYB6QlFGEg@public.gmane.org>]

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?).