Re: user-cr thread safety

[Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>]

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.