Fix windows issue with multiple workers

Sergey Brester serg.brester at
Thu Jun 18 09:23:37 UTC 2015

So, in VM it work for me also.

I'm assuming that something on my windows work-pc has prevented to 
inherit listener in this way (driver, LSPs installed (Layered Service 
Providers), antivirus or something else)...

But, why don't you want to use a suggested solution of me?

If I will realize the way with "easy" inheritance (with "bInheritHandle" 
through CreateProcess), it will be not really easier, because:

- we have several listener to share, so we should tell all this handles 
to child process;

- bInheritHandle=True in CreateProcess can be a potential risk by not 
closed handles, if process crashed, and that are not only sockets - thus 
will arise so-called zombi-handles as half-open (dropped) or 
half-closed. But for sockets are listening it is extrem. Here is an 
example when this situation is encountered (* - listener, which process 
does not exist):

netstat /ano | grep 0.0:80
  * TCP                 LISTENING       
    TCP                 LISTENING       

taskkill /F /PID 3824
ERROR: The process "3824" not found.

Unfortunately, it is not guaranteed that new process 4378 accepts 
connections (because "zombi" listener of 3824 can block it).
But also not so good are another zombies, like not closed temp-files, 
lock-files, pipes etc.

You can talk long about "that would be windows bugs", but that are 
facts. And thus it is instable. Apart from, does not work at all on some 
mashines (like my work-pc).
And the way with WSADuplicateSocket self Microsoft recommends in various 

If you still want to use the solution with "bInheritHandle", I suggest a 
I will make it with selectable option (resp. defines like 

Please tell me your decision.


Am 17.06.2015 16:52, schrieb Maxim Dounin:

> Hello!
> On Wed, Jun 17, 2015 at 04:01:17PM +0200, Sergey Brester wrote:
>> Hmm, strange - almost same code, but it does not work... only first 
>> child can accept connections.
> Have you tried exactly the code I provided? "Almost the same"
> is a usual difference between working and non-working code.
>> Which version of windows are you using for test?
> Works fine at least in Windows 7 and Windows 8.1 VMs here, both
> 32-bit. I have no 64-bit Windows on hand to test, but if it
> doesn't work for you specifically on 64-bit Windows, this may be
> some minor bug in the test code related to type casting.

More information about the nginx-devel mailing list