enable reuseport then only one worker is working?

[Jim Ohlstein]

Hello,

> On Mar 1, 2016, at 9:35 AM, Maxim Konovalov <maxim at nginx.com> wrote:
> 
>> On 3/1/16 5:23 PM, 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.
> Jim, we don't have any FreeBSD core team members on payroll.

Perhaps you can understand my confusion when I see multiple references to it online, including this tweet. https://mobile.twitter.com/maximkonovalov/status/486847353484480512. 

That, and the recent work sponsored by Nginx on FreeBSD sendfile(2) to be included in the upcoming release (11). If he is no longer on the payroll he is still working closely with you, so this hardly invalidates my premise that you would be aware of future changes in FreeBSD behavior.  ;)

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160301/778692eb/attachment.html>