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>