[PATCH] add reload_delay directive

Peng Fang fangpeng1986 at gmail.com
Mon Jun 19 15:39:14 UTC 2017


Hello, Maxim,

Thanks for your detailed explanation and I truly agree with you.

2017-06-19 23:28 GMT+08:00 Maxim Dounin <mdounin at mdounin.ru>:

> Hello!
>
> On Mon, Jun 19, 2017 at 11:09:58PM +0800, Peng Fang wrote:
>
> > # HG changeset patch
> > # User RocFang <fangpeng1986 at gmail.com>
> > # Date 1497882783 0
> > # Node ID 8b9e416ef7f9f8e7f96eaa53b479062683464481
> > # Parent  a39bc74873faf9e5bea616561b43f6ecc55229f9
> > Introduced reload_delay.
> >
> > Previously, the master process will sleep 100ms before sending a
> > SHUTDOWN signal to old worker processes when reload. This patch
> > make the sleep time configurable, because in some scenarios, the
> > new workers may spend more than 100ms to get ready. For example,
> > the init_prcess hook of some 3rd modules may be time-consuming.
>
> The sleep in question is intended to let OS some time to actually
> start the process, and not intended to allow time-consuming work
> to happen on a worker process start.
>
> In general, no time-consuming operations are expected to be done
> during a worker process start.  Instead, time-consuming
> preparatory work is expected to happen in the context of the
> master process during configuration parsing and init module hooks.
> If a module does something time-consuming in the init process
> hook, it might be a good idea to change the module logic.
>
> Unless there is something more specific than a "the init_prcess
> hook of some 3rd modules may be time-consuming", I would rather
> reject the patch, as it introduces unneeded user-level complexity
> by adding a directive, and encourages bad module writing practice.
>
> Nevertheless, thank you for the patch.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170619/40691b94/attachment.html>


More information about the nginx-devel mailing list