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.bavs...@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 _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-devel
