<div dir="auto"><div dir="auto">hello，Dounin,</div><div dir="auto"><br></div><div dir="auto"> I also had read many discussions , confusing how to properly maintain the dependency orders. So despite the usage of thread pool module, I think it's a principal to call the plugin's construction , then call their destruction functions in reverse order, when we design some kind of dynamic plugin mechanism.</div><div dir="auto"><br></div><div dir="auto">Does that make sense?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Or nginx has some consideration to force destruction follow same execution order with construction?<br><br><br>Thanks & Regards</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, 28 Apr 2022, 07:55 Maxim Dounin, <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Sun, Apr 24, 2022 at 04:33:04PM +0800, <a href="mailto:shanlei@asiainfo.com" target="_blank" rel="noreferrer">shanlei@asiainfo.com</a> wrote:<br>
<br>
> # HG changeset patch<br>
> # User stdanley <<a href="mailto:shanlei@asiainfo.com" target="_blank" rel="noreferrer">shanlei@asiainfo.com</a>><br>
> # Date 1650788278 -28800<br>
> #      Sun Apr 24 16:17:58 2022 +0800<br>
> # Node ID 522acbe88486d027383075c8208edd6fcc0a3aa6<br>
> # Parent  a736a7a613ea6e182ff86fbadcb98bb0f8891c0b<br>
> patch: call modules' exit_process in reverse order to solve module <br>
> dependency.<br>
> We once have developed a module which depends on ngx_thread_pool module. <br>
> but nginx hungs when began to shutdown. trace shows that ngx_thread_pool <br>
> cant finish "exit_process" because our module is using a thread, our <br>
> module must<br>
> call "exit_process" before ngx_thread_pool.<br>
> so we present this patch to solve modules' dependency issue.<br>
<br>
Thank you for the patch.<br>
<br>
First of all, you may want to consider this section in the <br>
development guide:<br>
<br>
<a href="http://nginx.org/en/docs/dev/development_guide.html#threads_pitfalls" rel="noreferrer noreferrer" target="_blank">http://nginx.org/en/docs/dev/development_guide.html#threads_pitfalls</a><br>
<br>
Using threads in nginx is usually a bad idea.  Thread pools, in <br>
particular, are designed to be used to offload short operations like <br>
read() syscalls.  And these operations are expected to be finished <br>
before nginx exit, so thread pool's exit handler waits for all <br>
threads to complete.<br>
<br>
If you are sure you have to use threads, and thread pools in <br>
particular, and with some long-running tasks, you may want to <br>
consider other ways to signal your threads to exit.  In <br>
particular, checking ngx_exiting/ngx_quit/ngx_terminate <br>
periodically might be a way to go.  Though I would recommend to <br>
reconsider using long-running thread tasks anyway.<br>
<br>
As for the patch, it looks wrong to me.  While changing the <br>
exit_process() callback order might solve your particular <br>
dependency issue, similar issues might easily appear with any <br>
order.<br>
<br>
Hope this helps.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list -- <a href="mailto:nginx-devel@nginx.org" target="_blank" rel="noreferrer">nginx-devel@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-devel-leave@nginx.org" target="_blank" rel="noreferrer">nginx-devel-leave@nginx.org</a><br>
</blockquote></div></div>