[omniORB] RE: Fork/Exec

[GAO,YAN (HP-Singapore,ex3)]

Hi, Sandro,

I have the similar problem like yours. I also want to do the fork/execl in a
method and continue to get all sorts of problems. If you resolve your
problems, can I share some of your experience? How do you workaound it. I am
using HP-UX 11.0

Best Regards,

Gao Yan


-----Original Message-----
From:	Duncan Grisby [mailto:dgrisby@uk.research.att.com]
Sent:	Tuesday, February 13, 2001 7:12 PM
To:	Sandro Tolaini
Cc:	omniorb-list@uk.research.att.com
Subject:	Re: Fork/Exec (Was: Re: [omniORB] Python 2, FreeBSD 4,
omniORBpy, core dump) 

On Monday 12 February, "Sandro Tolaini" wrote:

> Another question about OmniORB on multiple platforms: I need to do a
> fork/exec in a method. It seems that not closing all the file descriptors
> (except for cerr,cin, cout) in the child process after fork() but before
> exec() results in a general mess (i.e. the client who called the method
that
> did the fork/exec dies with an unexpected exception). Now I close all the
> file descriptors by looking into the /proc/self/fd dir, but this holds
only
> for Linux. Is there a better way to do that? All the fd have the
> CLOSE_ON_EXEC flag set, but it does not work as expected.

Forking from multi-threaded programs tends to cause all sorts of
difficulties. It's often best to avoid the problem by adding an extra
level of indirection:

As the very first thing your server program does, before it calls
ORB_init(), create a pipe, and fork. The parent process (or the child,
for that matter) then goes on to ORB_init() and so on. The child
process sits listening on the pipe. Now whenever you want to fork from
within a method, send a message into the pipe containing all the
information needed by the new process. The process listening on the
pipe can then do the fork safely.

This is all very easy unless you need to pipe results back from the
forked processes. In that case, you'll have to start messing with
named pipes, or implement your own multiplexing over a single pipe.

I've no idea how this applies to the Windows world.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --