On 01/03/16 14:23, Jim Ohlstein wrote:
Hello,
On 3/1/16 8:34 AM, Andrew Hutchings wrote:
Hi Jim,
On 01/03/16 13:10, Jim Ohlstein wrote:
Hello,
On 2/28/16 11:22 PM, Валентин Бартенев wrote:
On Sunday 28 February 2016 08:52:12 meteor8488 wrote:
Hi All,
I just upgrade Nginx from 1.8 o 1.9 on my FreeBSD box.
[..]
Did I miss anything in the configuration? or for a busy server, it's
better
to use accept_mutex instead of reuseport?
[..]
In FreeBSD the SO_REUSEPORT option has completely different behavior
and shouldn't be enabled in nginx.
Should the configruation option then be disabled or silently ignored in
FreeBSD at this time?
It would be difficult to selectively ignore operating systems based on
how this function is supported. Especially if that support changes over
time.
I don't claim to know how "difficult" that would be, but with all the
extremely talented coders in the Nginx group, I would think that
"difficult" would not be a barrier to "doing it right". If OS support
changes, nginx can change. Something tells me that with a FreeBSD Core
Team member on the Nginx payroll, if this OS feature changes, it'll
filter through to the people who write the code.
This would be more a case of effort / payoff. I'm not saying it isn't
technically possible. But effort may be better spent implementing new
features people have been asking for (we have some kick-ass stuff
upcoming). Rather than implementing an OS kernel version detection with
blacklist.
If I choose to try "use kqueue" on a system that does not support that
event method, I am hoping nginx would either tell me by refusing to
start, or ignore my stupidity. Similarly, if I attempt to enable
"reuseport" on Solaris or Windows which (I guess) do not support
SO_REUSEPORT, nginx will inform me. I know this happens on FreeBSD with,
for instance, aio. If aio is not built in to the kernel (it is not by
default), or specifically loaded, nginx gives an error and won't start.
In the case of SO_REUSEPORT, the OS call has virtually the opposite of
the desired effect.
Comparing it to kqueue isn't quite the same. On operating systems that
do not support SO_REUSEPORT (including older Linux kernels) you will not
be able to use the option at all. The problem here is FreeBSD has the
option, it just has a different behaviour. I'm not even sure it is
possible to detect in a build system without maintaining a blacklist.
If a directive has the potential for significantly bad consequences, it
should be spat out during config testing with at least a warning.
I have mixed feelings on this. I believe for a majority of users this
isn't a problem so users will see a warning that could concern them when
in reality in a majority of cases it doesn't affect them.
Since it isn't enabled by default a user would have to research and make
a conscious choice to turn it on. I would hope at this point the user
would have made an informed decision when enabling tuning directives.
Kind Regards
--
Andrew Hutchings (LinuxJedi)
Technical Product Manager, NGINX Inc.
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
