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 > <[email protected]> wrote: > >> This allows adding a tcp/ip socket and adds tracking of the >> remote status for clients and proxies >> >> Signed-off-by: Derek Foreman <[email protected]> --- >> 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 > _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
