"closeOnExec" semantics in .NET with System.Net.TcpListener and System.Diagnostics.Process.Start()

[Doug Wyatt]

So I'll preface this with the fact that I'm a UNIX developer by training and
have just recently gotten in to C# development on Windows. I'm basically
running in to a problem whereby I suspect something to do with process
groups or threads and closeOnExec semantics (to speak in POSIX terms) is
causing me a problem. I've got a windows service (let's call it
"myService") that, among other things, does :
onStart
creates a TcpListener on a port and starts it

onStop
calls stop on the TcpListener

In addition, while it's running, I can cause the service to "spawn" another
program that invokes "net stop myService" and then "net start myService".
After that, the new instance of myService doesn't seem to be listening on
the port. If I call "net stop myService" and "net start myService" from a
separate shell, everything works fine.

This makes me think that something about the fact that I'm spawning the
killer from within the service keeps some remnants of the TcpListener
around, which keeps the next instance of it from being able to bind to that
port. In POSIX terms, it's like I didn't have closeOnExec set on my socket
so the child inherited it. But I don't really understand the semantics of
process forking and network connections in the .NET and Windows world.

I use System.Diagnostics.Process.Start() to spawn my child process (and just
never call WaitForExit() so it works like a fork/exec). Should I be using a
different mechanism to create this new process such that it doesn't inherit
the TcpListener? Should I be marking my TcpListener in some way so that it
gets closeOnExec semantics? Or is there a better newsgroup to ask this
question in (admittedly, this is more a .NET question than a C# question,
but it's C# code)

Thanks,
Doug

 

[Jon Davis]

see my post on the other thread