[Mono-dev] close on exec
jacobgladish at yahoo.com
Tue Sep 30 15:56:37 EDT 2008
--- On Tue, 9/30/08, Kornél Pál <kornelpal at gmail.com> wrote:
> From: Kornél Pál <kornelpal at gmail.com>
> Subject: Re: [Mono-dev] close on exec
> To: jacobgladish at yahoo.com
> Cc: mono-devel-list at lists.ximian.com
> Date: Tuesday, September 30, 2008, 2:18 PM
> MS .NET creates new processes with handle inheritance
> enabled but on
> Windows only handles maked as inheriable are inherited to
> the new process.
> When using System.Diagnostics.Process.Start() mono closes
> descriptors in the forked process.
> But if you call fork() it is your responsibility to close
> Handles can only be closed safely right after fork() so if
> you don't
> have access to the source code of the library you can't
> fix it.
This is exactly my problem. I do not have source. What I'm left to do is attempt to find all the fd's in question (in my code) and use Mono.Unix.Native.Syscall.fcntl() to set close-on-exec. This obviously doesn't work well since someone else may add new streams to the codebase, and I'm using other 3rd party assemblies (like log4net).
> You can however create a subprocess using Process.Start()
> that will not
> contain the socket handle because Mono properly closes
> those file
> descriptors. But there still will be some leaked file
> descriptors from
> the new Mono process so you should create a native wrapper
> executable to
> minimalize the leakage.
> Jacob Gladish wrote:
> > I'm using p/invoke in my code and the library
> I'm calling into may call fork()/exec(), at which point
> the new process has dup'd copies of some of my open
> files. Sadly, one was a tcp listener, which means if I
> restart my application the bind() fails when I create an
> instance of a TcpListener. I'm curious if anyone can
> confirm the windows/.net behavior for this situation. As far
> as I know win32 handle inheritance is off unless specified,
> which leads me to believe that all fd's should be set
> close on exec by the mono runtime on unix variants.
More information about the Mono-devel-list