[Spread-users] after fork: session 'xxx' trying to make session 'yyy' do something

[James Rauser]

Yair Amir wrote:
> 
> Hi,
> 
> Try not touching the original connection. Just connect in the child
> with a new name and use that new connection and see if that works.
> I know it is not nice to leave the first connection opened in the
> child but I would first verify that your closing it is the problem.
> 
>     Cheers,
> 
>     :) Yair.

Yes I've verified this already; the problem occurs *only* when the
child's connection gets the same FD as the parent; if I don't close the
inherited FD, then the child will obviously get a different.  In the
long run, though, just leaving the inherited connection open is not an
option; the child may in some cases also be a long running process,
perhaps even outliving the parent.

> James> Yair Amir wrote:
> >>
> >> I miss some information. For example I need to see the EXACT
> >> SP_multicast call you do (including all of its parameters).
> >>
> >>              :) Yair.
> 
> James> The basic question is: how can I get rid of an inherited spread connection
> James> in a forked child process *without* disconnecting the parent process?
> James> Just doing a close() on the mbox gets rid of the unix file descriptor,
> James> but apparently doesn't update the session table maintained in the client
> James> library, which then leads to inconsistencies in the communication with
> James> the daemon.  Doing an SP_disconnect() in the child will clean up the
> James> session table, but will also disconnect the parent.  Note that I don't
> James> exec() anything in the child, so the fd's close-on-exec flag is
> James> irrelevant.
> 
> [lots of detail snipped]

Thanks, Jim

-- 
------------------------------------------------------------------------
Jim Rauser                                          Science Factory GmbH
mailto:j.rauser at science-factory.com                       Unter Käster 1
Tel: +49 221 277 399 204                          50667 Cologne, Germany