[PATCH 8 of 9] Upstream: disable re-resolve functionality on Windows

[Roman Arutyunyan]

Hello,

On Wed, Jul 10, 2024 at 05:16:07PM +0400, Roman Arutyunyan wrote:
> Hi,
> 
> On Thu, Jun 13, 2024 at 03:29:03PM -0700, Aleksei Bavshin wrote:
> > # HG changeset patch
> > # User Aleksei Bavshin <a.bavshin at nginx.com>
> > # Date 1712181327 25200
> > #      Wed Apr 03 14:55:27 2024 -0700
> > # Node ID 375fa42f1a6010692a8782c4f03c6ad465d3f7f7
> > # Parent  8c8d8118c7ac0a0426f48dbfed94e279dddff992
> > Upstream: disable re-resolve functionality on Windows.
> > 
> > Following features are currently not implemented on Windows, making re-resolve
> > functionality unsafe to use:
> > 
> >  * 'noreuse' shared zones that are re-created on each configuration reload.
> >    The work scheduling logic is not prepared to handle simultaneous access to
> >    the shared zone from multiple generations of the worker processes.
> 
> I don't see a problem here.  Could you please elaborate.
> 
> >  * 'ngx_worker' identification.
> >    It is possible to configure multiple worker processes on Windows, even if
> >    only one would actually handle the traffic.  All of the worker processes are
> >    currently identified as process 0, breaking scheduling and locking of the
> >    resolver tasks.
> 
> This can be fixed.  Patch attached.


[..]

More thoughts on this.

It's known that even though nginx for Windows may be configured to have
multiple workers, only one of them actually accepts connections:

https://nginx.org/en/docs/windows.html

This makes multi-worker Windows configuration useless.  However since they
are allowed, these workers at least should not crash.  And this is where the
problems with upstream resolve arise.  Since ngx_worker is always zero, all
workers will identify as #0 and will start upstream serevr name resolutions.
With current patches this will cause worker crashes since the resolve event
object is allocated in shared zone.  If we remove it from the zone and allocate
it locally with ngx_alloc() instead, the problems with Windows will go away.
All workers will safely resolve the same names, which makes zero sense, so
as having multiple workers in the first place.  And I generally think it's
better to allocate process-local data locally to avoid memory overuse and
potential confusions.  In this case my last ngx_worker patch is not needed.

--
Roman Arutyunyan