Hi Valentin,

Thanks very much for your email.

Regarding to your first question, I did following test:
1. Start Nginx
2. Offline half of the CPU threads by "echo 0 > /sys/devices/system/cpu/"cpu#"/online
3. Reload Nginx and check the worker process, the number of listen sockets is actually reduced to half.
4. Then, I put back the offlined CPU threads back online, and reload the Nginx again.
5. The new worker process now has 2X listen sockets as the CPU threads doubled since the previous reload.

Every time Nginx reloads, my understanding is it will run Ngx_init_cycle. CPU_num_check is there. Is above testing the correct way to check if reload works? Please let me know if I missed anything.

Regarding to your second question, I will double check the code style and resend an update.

Thanks again for your help and comments!
Yingqi


-----Original Message-----
From: nginx-devel-bounces@nginx.org [mailto:nginx-devel-bounces@nginx.org] On Behalf Of Valentin V. Bartenev
Sent: Friday, September 19, 2014 1:37 AM
To: nginx-devel@nginx.org
Subject: Re: [Patch] SO_REUSEPORT support from master process

On Thursday 18 September 2014 20:05:39 Lu, Yingqi wrote:
> Dear All,
>
> Here is the updated patch for SO_REUSEPORT support enablement on Linux
> OS (attached below). The changes in this version are:
>
> 1. Solve the issue with "binary upgrade on the fly" feature. Thanks to
> Sepherosa Ziehau for his feedback! With this version of patch, there
> is no issue or connection loss during the binary upgrade. I tested on
> RHEL 6.5 (with kernel 3.13.9) and CentOS 7. Both are working fine. The
> new master process inherited all the previous listen sockets during
> the upgrade and new children processes inherited from the new master.
> Also, the workload data show there is no connection loss or
> performance impact during the binary upgrade.
>
> 2. Make the duplication of listen sockets happen in the function
> ngx_http_init_listening instead of ngx_init_cycle.
>
> Please review it and let me know your questions and comments. Thanks
> very much for your time reviewing the patch.
[..]

How do you deal with changed number of online cpus since last reload?

Please note, that there's no way for a patch to be approved with such number of style issues. You should consult with:
http://nginx.org/en/docs/contributing_changes.html#formatting_changes

wbr, Valentin V. Bartenev

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel