Fix windows issue with multiple workers

Sergey Brester serg.brester at sebres.de
Thu Jun 11 13:03:34 UTC 2015


 

Hi, 

I've forgotten to free the shmem, thus enclosed an amendment with
clean-up, relative last changeset. 

Regards,
sebres. 

10.06.2015 21:48, Sergey Brester: 

> 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 [2] 
> 
> Here [3] 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). 
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel [1]
 

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


More information about the nginx-devel mailing list