[PATCH wayland] increase server listen queue to 8

[Imran Zaman]

Actually we were connecting multiple simultaneous child/session
westons to system weston and sometime it didn't succeed. Nevertheless
we are not sure that this can be one of the reasons and we couldnt
spot the problem precisely (we were testing it in Tizen with kernel
version: 3.14.19-10.4)

We thought this can be one of the reasons if multiple clients ask for
simultaneous connections.

As you said its harmless, its better to increase the length anyways..

Thanks for the links. I can push the patch again after rebasing and
changing queue length to 128.

BR
imran

On Wed, Nov 19, 2014 at 12:22 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 15 Oct 2014 16:43:34 +0300
> Imran Zaman <imran.zaman at gmail.com> wrote:
>
>> Hi
>>
>> This will allow more than 1 simultaneous client connections to the server
>> without the possibility of connection refused error. possible use case
>> is multiple session
>> compositors can connect to the system compositor simultaneously.
>>
>> ----
>>
>> diff --git a/src/wayland-server.c b/src/wayland-server.c
>> index 674aeca..e3b7d9f 100644
>> --- a/src/wayland-server.c
>> +++ b/src/wayland-server.c
>> @@ -1126,7 +1126,7 @@ _wl_display_add_socket(struct wl_display
>> *display, struct wl_socket *s)
>>   return -1;
>>   }
>>
>> - if (listen(s->fd, 1) < 0) {
>> + if (listen(s->fd, 8) < 0) {
>>   wl_log("listen() failed with error: %m\n");
>>   return -1;
>>   }
>
> This patch is obviously format-broken, but the change itself seems
> harmless to me. Since no-one has commented on it, I suppose no-one is
> against it.
>
> I also found:
> http://utcc.utoronto.ca/~cks/space/blog/unix/ListenBacklogMeaning
> which suggests that the number is fairly arbitrary.
>
> I couldn't find a clear explanation what the backlog argument means for
> unix domain sockets, either. However, I did find a random comment:
> http://stackoverflow.com/questions/19221105/connect-with-unix-domain-socket-and-full-backlog
> That suggests that on Linux you might rather see EAGAIN than
> ECONNREFUSED. Sounds like it's not completely true?
>
> So, since we have no reason to artificially limit the queue, let's go
> with something big. Say, 128.
>
> Would you like to spin a proper patch, or shall I just rewrite this in
> my own name?
>
> Would be nice to hear how you actually hit the connection refused, and
> on what OS/kernel.
>
>
> Thanks,
> pq