[Spread-users] Spread and fork ()

John Schultz jschultz at cnds.jhu.edu
Wed Nov 24 12:30:07 EST 2004

On Tue, 23 Nov 2004, J C Lawrence wrote:

> On Tue, 23 Nov 2004 12:05:36 -0500
>  spread_handle.disconnect ()
>  pid = os.fork ()
>  if pid != 0: # Parent
>    spread_handle = spread.connect (...)
>    spread_handle.join (...)
>    ...etc
>  else: # Child
>    spread_handle = spread.connect (...)
>    spread_handle.join (...)
>    ...etc
> Is this unsafe?
> ...
> Is there a potential for that to still be true in the above disconnected
> case?

Using the C library (I'm not sure about the Python library), so long as no 
other threads are in a SP_* call at the time of the fork(), then it is 
safe.  If other threads are in a SP_* call at the time of the fork(), then 
the internal mutexes of the Spread library may be unlockable in the child 
and it probably won't work.  This is because the Spread library doesn't 
install pthread_atfork() handlers to reset the mutexes in the child 
process at fork().

What isn't supported at all is sharing (i.e. - using) the same connection 
in two different processes at the same time.

   spread_handle = spread.connect(...)
   pid = os.fork ()
   # both parent and child continue using spread_handle

Off hand, I don't know if you could have one process only do receives and 
the other only do multicast and have it work or not ... probably not 

If you care about releasing unnecessary/unused file descriptors in the 
different processes after a fork, then you will need to export and use the 
internal SP_kill() fcn as Yair suggested.

I haven't tried it, but I see no obvious reason why a Spread connection 
couldn't be handed off to a child process through fork().  You would 
simply have to either keep the connection open and unused in the parent or 
use SP_kill().

   spread_handle = spread_handle.connect(...)
   if pid != 0: # Parent kills spread_handle
   else: # Child uses already set up spread_handle

I said Spread doesn't really support the fork() process model because of 
the multi-threaded mutex problem and because the internal SP_kill() fcn 
needs to be exported.  It can be made to work pretty well with this model, 
but it won't work as expected "straight out of the box."

John Schultz
Spread Concepts
Phn: 443 838 2200

More information about the Spread-users mailing list