Re: socket in LISTENING state after a call to closesocket
- From: "boris" <somewhere@xxxxxxxxxxx>
- Date: Sat, 11 Apr 2009 04:36:06 -0700
"Ben Voigt [C++ MVP]" <rbv@xxxxxxxxxxxxx> wrote in message news:eprasJWuJHA.5836@xxxxxxxxxxxxxxxxxxxxxxx
But not all handles are inherited: only those that were created as inheritable (via bInheritHandle field of SECURITY_ATTRIBUTES struct) or if DuplicateHandle() or SetHandleInformation() were called.My question was why the socket was still in LISTENING mode after IThe socket is release when I kill the subprocess. I have used
calc.exe as subprocess with the same behavior.
What was your question? It sounds as if subprocesses are being
created with the "inherit handles" capability enabled. Until the
subprocess closes its handle, the socket isn't really closed. Or
something like that.
called closesocket but your answer raised another question. "inherit
handles" capability, how does it work and how do I turn it off on a
process started from managed code.
You can't, because it's not an attribute of the process. It's controlled at the time the child process is launched.
In Windows, all methods of starting a process eventually call CreateProcess
http://msdn.microsoft.com/en-us/library/ms682425(loband).aspx
Apparently Process.Start or whatever you are using to start a child task is passing TRUE as the value of bInheritHandles. And if the framework is starting a child task somewhere, somehow, and allowing it to inherit handles.... then you're pretty much at its mercy. But I would be surprised to find out that the framework is doing something so stupid. More likely it's a global Windows hook or other injected DLL (things like multi-monitor management programs often install these) that is making unauthorized duplicates of your handle.
Even if socket() creates inheritable handle, it should be possible to change it to non-inheritable: by calling SetHandleInformation() after socket was created.
Boris
.
- References:
- socket in LISTENING state after a call to closesocket
- From: vojat
- Re: socket in LISTENING state after a call to closesocket
- From: Ben Voigt [C++ MVP]
- Re: socket in LISTENING state after a call to closesocket
- From: vojat
- Re: socket in LISTENING state after a call to closesocket
- From: Ben Voigt [C++ MVP]
- socket in LISTENING state after a call to closesocket
- Prev by Date: Re: socket in LISTENING state after a call to closesocket
- Next by Date: Re: setting socket option by setsockopt() have no effect
- Previous by thread: Re: socket in LISTENING state after a call to closesocket
- Next by thread: Re: 16ms delay is every 5th WSARecv?
- Index(es):
Relevant Pages
|