[PATCH] wayland-server: update the client fd when it failed to flush with EAGAIN

[Pekka Paalanen]

On Wed, 28 Nov 2018 09:49:54 +0900
박성진 <sj76.park at samsung.com> wrote:

> > On Tue, 27 Nov 2018 17:59:16 +0900
> > 박성진 <sj76.park at samsung.com> wrote:
> 
> > > Hi Derek>> On 11/22/18 11:08 PM, Jeonghyun Kang wrote:
> 
> > > > What if it's a frame event that gets dropped and not an input event?  Or
> > > > a resource destroy?
> > > Instead of destroying a connection, destroying a resource seems to be more
> > > reasonable.
> 
> > No, you cannot do that either. It too will cause the client and the
> > server to get out of sync, which may eventually lead to a fatal
> > protocol error.
> 
> > Really, the only thing you can do is either disconnect the client or
> > halt its connection until it drains. Halting would require explicit
> > support throughout the compositor to avoid sending any events, so
> > disconnecting is the only thing that libwayland-server can do by itself.
> 
> Oops ! Actually I had to say "removing/re-creating resources like
> wl_touch interface by updating capabilities via wl_seat capabilities
> event seems better than destroying the client." As we have an
> electronic whiteboard products that can be drawn with 4 pens
> simultaneouly in high resolution, killing an important app that draws
> trajectories of each pen may not be the best option.

That is going to be difficult as well, because to revoke a capability
you need to send an event and only then the compositor can decide to
stop sending the related input events. Sending an event will be hard
when the send buffers are already full.

It would also just remove one kind of event source from the client, but
you still have lots of other event sources that you cannot revoke this
way, and they also need to continue working. That will be very hard when
the send buffers are already full.

What you are thinking of here is just a tiny piece of the "halt the
connection" approach, and I very much doubt it alone would do any good.

Also, removing capabilities might prevent disconnects, but it will
still have the app misbehave from a user perspective, making the system
look broken in any case. I think it would be better to primarily avoid
ending up with overflowing messages, and secondary when it happens,
make it very obvious it happened so you get clear error reports, and
then recover by e.g. re-connecting if possible. I don't think papering
over the issue and obfuscating the symptoms would be a good idea.

> Now we're going to do the further analysis about how many events are
> coming from kernel/compositor and how fast the client can process the
> events.

Keep your messages as small as possible, and return to your main event
loop to flush and read the socket as often as possible. That's the only
general advice coming to my mind.

Everything else will be kind of case by case, e.g. you might be
able to compress pointer motion events in the compositor if the input
device is sends too many too fast. Of course, compressing motion events
means that the client no longer sees the true trajectory but some
approximation of it.

Sometimes you may have to change your protocol design. If you need to
send a lot of data in one go, consider using shared memory instead of
many and/or big messages.


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