Fix windows issue with multiple workers

Sergey Brester serg.brester at sebres.de
Wed Jun 10 19:48:28 UTC 2015


 

Hi, 

enclosed you will find an attached changeset, that contains fix for
windows issue with multiple workers (once listening - only one made any
work). 

If someone needs a git version of it: 

https://github.com/sebres/nginx/pull/1/files [1] 

Here [2] you may find a benchmark comparison for that (1 worker column -
measured before fix). 

-- 

Shortly about fix algorithm (changes related are marked as [*],
unchanged - [-]): 

- master process create all listener; 

- [cycle] master process create a worker; 

* [win32] master calls `ngx_share_listening_sockets`: each listener
share (inheritance) info for pid of this worker ("cloned" via
WSADuplicateSocket), that will be saved in shmem; 

- master process wait until worker will send an event "worker_nnn"; 

* [win32] worker process executes `ngx_get_listening_share_info` to
obtain shared info, protocol structure that can be used to create a new
socket descriptor for a shared socket; 

* [win32] worker process creates all listener sockets using given shared
info of master; 

- worker process sets an event "worker_nnn"; 

- master process create next worker, repeat [cycle]. 

-- 

@Maxim Dounin:
1) your suggested way with shared handle and bInheritHandle does not
work, because of:
[quote]
Sockets. No error is returned, but the duplicate handle may not be
recognized by Winsock at the target process. Also, using DUPLICATEHANDLE
interferes with internal reference counting on the underlying object. 
To duplicate a socket handle, use the WSADUPLICATESOCKET function.
[/quote] 

2) proposal to use an environment instead of shared memory can not work
also, because sharing via WSADuplicateSocket should already know a pid
of target process, that uses this handle - specially shared for each
worker. 

BTW, using of `accept_mutex` was disallowed for win32, cause of possible
deadlock if grabbed by a process which can't accept connections.
Because, this is fixed now, I have removed this "restriction" in
separated commit.
But I think, accept_mutex is not needed in win32 resp. with accept_mutex
it is much slower as without him. So, whats about set default of
`accept_mutex` to `off` on windows platform? 

BTW[2], I have executed extensive tests of this fix, also with reloading
(increase/decrease `worker_processes`), restarting, as well as
auto-restarting of worker, if it was "crashed" (ex.: have sporadically
killed some worker). 

Regards,
Serg G. Brester (aka sebres). 

 

Links:
------
[1] https://github.com/sebres/nginx/pull/1/files
[2] https://github.com/sebres/nginx/pull/1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20150610/58739758/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _sb-win-multi-worker.patch
Type: text/x-diff
Size: 13065 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20150610/58739758/attachment.bin>


More information about the nginx-devel mailing list