Hi all, Sorry for the top post. Any follow-up on this? Or I should just keep it as a local patch?
Best Regards, sephe On Fri, Aug 2, 2013 at 1:16 PM, Sepherosa Ziehau <[email protected]>wrote: > Hi all, > > Here is another round of SO_REUSEPORT support. The plot is changed a > little bit to allow smooth configure reloading and binary upgrading. > Here is what happens when so_reuseport is enable (this does not affect > single process model): > - Master creates the listen sockets w/ SO_REUSEPORT, but does not > configure them > - The first worker process will inherit the listen sockets created by > master and configure them > - After master forked the first worker process all listen sockets are > closed > - The rest of the workers will create their own listen sockets w/ > SO_REUSEPORT > - During binary upgrade, listen sockets are no longer passed through > environment variables, since new master will create its own listen > sockets. Well, the old master actually does not have any listen > sockets opened :). > > The idea behind this plot is that at any given time, there is always > one listen socket left, which could inherit the syncaches and pending > sockets on the to-be-closed listen sockets. The inheritance itself is > handled by the kernel; I implemented this inheritance for DragonFlyBSD > recently ( > http://gitweb.dragonflybsd.org/dragonfly.git/commit/02ad2f0b874fb0a45eb69750219f79f5e8982272 > ). > I am not tracking Linux's code, but I think Linux side will > eventually get (or already got) the proper fix. > > The patch itself: > http://leaf.dragonflybsd.org/~sephe/ngx_soreuseport3.diff > > Configuration reloading and binary upgrading will not be interfered as > w/ the first 2 patches. > > Binary upgrading reverting method 1 ("Send the HUP signal to the old > master process. ...") will not be interfered as w/ the first 2 > patches. There still could be some glitch (but not that worse as w/ > the first 2 patches) if binary upgrading reverting method 2 ("Send the > TERM signal to the new master process. ...") is used. I think we > probably just need to mention that in the document. > > Best Regards, > sephe > > -- > Tomorrow Will Never Die > -- Tomorrow Will Never Die
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
