From: Joel VanderWerf <vjoel@...>
Date: 2009-07-14T10:40:31+09:00
Subject: Re: Process.fork weirdness

Gary Wright wrote:
> 
> On Jul 13, 2009, at 1:18 PM, Joel VanderWerf wrote:
>> Huh, I never knew that. That's dangerous if the parent process is 
>> multithreaded, isn't it? Because even if the forking thread flushes 
>> all open files, other threads can keep filling buffers before the fork 
>> happens.
> 
> It is probably a bad idea to have multiple threads writing to a shared 
> file descriptor without proper synchronization.  With proper 
> synchronization you should be able to safely flush and fork.

I was thinking of situations in which one program component runs in a
worker thread and manages its own files, not shared with the main thread
(but the descriptors are shared in the same process of course). If the
files are log files, they would probably have IO#sync=true, so no danger
there. But what about a library using IO#write to talk http, a rest
client, let's say? This would not want IO#sync=true. It might not
really be possible to make the library aware of the need for 
synchronization around buffered writes. In this case, maybe it would be 
better to "firewall" the http library in its own process, and 
communicate over unix sockets.

Anyway, thanks for making me aware of one more thing to worry about!

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407