[RFC wayland 13/18] connections: Add remote sockets

[Derek Foreman]

Please forgive my mailer for what it's done to the content below. :/

On 10/02/16 07:33 AM, Pekka Paalanen wrote:
> On Tue,  9 Feb 2016 10:56:00 -0600 Derek Foreman
> <derekf at osg.samsung.com> wrote:
> 
>> This allows adding a tcp/ip socket and adds tracking of the
>> remote status for clients and proxies
>> 
>> Signed-off-by: Derek Foreman <derekf at osg.samsung.com> --- 
>> src/connection.c          |  11 +++- src/wayland-client.c      |
>> 103 +++++++++++++++++++++++++------- src/wayland-private.h     |
>> 5 ++ src/wayland-server-core.h |   7 +++ src/wayland-server.c
>> | 146 ++++++++++++++++++++++++++++++++++++---------- 5 files
>> changed, 221 insertions(+), 51 deletions(-)
>> 
>> diff --git a/src/connection.c b/src/connection.c index
>> 05806b6..5fd085f 100644 --- a/src/connection.c +++
>> b/src/connection.c @@ -39,6 +39,7 @@ #include <sys/socket.h> 
>> #include <time.h> #include <ffi.h> +#include <stdbool.h>
>> 
>> #include "wayland-util.h" #include "wayland-private.h" @@ -61,6
>> +62,7 @@ struct wl_connection { struct wl_buffer fds_in,
>> fds_out; int fd; int want_flush; +	bool remote; };
>> 
>> static int @@ -191,6 +193,12 @@ close_fds(struct wl_buffer
>> *buffer, int max) buffer->tail += size; }
>> 
>> +void +wl_connection_set_remote(struct wl_connection
>> *connection) +{ +	connection->remote = true; +} + int 
>> wl_connection_destroy(struct wl_connection *connection) { @@
>> -278,6 +286,7 @@ wl_connection_flush(struct wl_connection
>> *connection) char cmsg[CLEN]; int len = 0, count, clen; uint32_t
>> tail; +	int wait = connection->remote ? 0 : MSG_DONTWAIT;
>> 
>> if (!connection->want_flush) return 0; @@ -298,7 +307,7 @@
>> wl_connection_flush(struct wl_connection *connection)
>> 
>> do { len = sendmsg(connection->fd, &msg, -				      MSG_NOSIGNAL
>> | MSG_DONTWAIT); +				      MSG_NOSIGNAL | wait);
> 
> Hi,
> 
> why do you want to block for remote?
> 
> Could this be because something isn't polling for writable
> properly? Or don't we support that somehow?

This was failing with EAGAIN so I just dropped the dontwait without
thinking about it too much, but now that you're forcing me to...

We can technically fill up the send buffer and have this fail with
EAGAIN even on local connections, but it takes an unreasonably massive
amount of spew to do it - I made weston repeat mouse motion events
something like 10000 times as a test. :)

I don't think epoll telling us it's writable actually promises there's
enough room for a potentially 4k wayland packet.

With a remote network connection things backlog much more quickly...

Oh, and as you mentioned to me on irc, pushing "bulk data" through the
pipe with write(2) directly certainly doesn't make this any less
likely to happen.  (And neither does sending piles of 4k packets worth
of buffer contents, I guess)

I think it's been safe so far to assume that a full send buffer means
the app on the other end isn't responding at all, but with a tcp/ip
connection it isn't?

>> } while (len == -1 && errno == EINTR);
>> 
>> if (len == -1)
> 
> 
> Thanks, pq
>