"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.Diagnost ics.Process.Sta rt() 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]

Re: "closeOnEx ec" semantics in .NET with System.Net.TcpL istener and System.Diagnost ics.Process.Sta rt()

see my post on the other thread

"Doug Wyatt" <newsreader7@st arbak.net> wrote in message
news:uuGaijkqDH A.1724@TK2MSFTN GP10.phx.gbl...[color=blue]
> So I'll preface this with the fact that I'm a UNIX developer by training[/color]
and[color=blue]
> 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"[/color]
another[color=blue]
> 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[/color]
that[color=blue]
> port. In POSIX terms, it's like I didn't have closeOnExec set on my[/color]
socket[color=blue]
> 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.Diagnost ics.Process.Sta rt() to spawn my child process (and[/color]
just[color=blue]
> never call WaitForExit() so it works like a fork/exec). Should I be using[/color]
a[color=blue]
> different mechanism to create this new process such that it doesn't[/color]
inherit[color=blue]
> the TcpListener? Should I be marking my TcpListener in some way so that[/color]
it[color=blue]
> 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
>
>[/color]