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

[Pekka Paalanen]

On Wed, 10 Feb 2016 11:49:05 -0600
Derek Foreman <derekf at osg.samsung.com> wrote:

> 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

> >> +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...

Hi,

hrm, does this mean that we try to send the whole send-buffer's worth
of data in one go, and if it doesn't fit, we give up completely on this
event loop cycle rather than trying to send just some of the messages?

If that's true, a slow client would cause the server to busy-spin with
the socket polling readable until there is room for the whole mass, and
that doesn't sound too good.

I fear fixing this would be quite hard. Ok, I see blocking is the easy
way out.

> 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?

That seems like a hasty assumption to me. OTOH, libwayland-client tries
to read as much as possible, doesn't it? I mean, it will usually read
everything there is coming, which on a local connection means that
there will be room for the "whole mass" the next time. And tcp/ip
doesn't work like that because the server's send queue may drain little
by little?

I suppose this is one of the reasons why libwayland as is, being
optimized for local transport, is not a good fit for the network.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160211/871d6c11/attachment-0001.sig>