SO_REUSEPORT: strange kernel balancer behaviour

[Adrian Chadd]

i've noticed this when doing this stuff in a threaded program with
each thread listening on the same port.

All threads wake up on each accepted connection, one thread wins and
the other threads get EAGAIN.



-adrian

On 15 July 2013 12:31, trafdev <trafdev at mail.ru> wrote:
> Thanks for reply.
>
> This approach produces lot of "resource temporary unavailable" (eagain) on
> accept-ing connections in N-1 processes.
> Is this possible to avoid this by e.g. tweaking kqueue?
>
>
> On Sun Jul 14 19:37:59 2013, Sepherosa Ziehau wrote:
>>
>> On Sat, Jul 13, 2013 at 1:16 PM, trafdev <trafdev at mail.ru> wrote:
>>>
>>> Hello.
>>>
>>> Could someone help with following problem of SO_REUSEPORT.
>>
>>
>> The most portable "load balance" between processes listening on the
>> same TCP addr/port probably is:
>>
>> s=socket();
>> bind(s);
>> listen(s);
>> /* various socketopt and fcntl as you needed */
>> pid=fork();
>> if (pid==0) {
>>      server_loop(s);
>>      exit(1);
>> }
>> server_loop(s);
>> exit(1);
>>
>> Even in Linux or DragonFly SO_REUSEPORT "load balance" between
>> processes listening on the same TCP addr/port was introduced recently,
>> so you probably won't want to rely on it.
>>
>> Best Regards,
>> sephe
>>
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"