how to handle the last_error of wl_display

[Pekka Paalanen]

On Thu, 21 Jun 2018 11:59:57 +0800
zou lan <nancy.lan.zou at gmail.com> wrote:

> Hi pekka
> 
> I find the last_error is caused by
> wl_display_flush()-->wl_connection_flush(). The sendmsg() return fail.
> 
> Many applications write code like this:
> 
> redraw()
> {
> wl_surface_commit();
> wl_display_sync();
> wl_display_flush();
> }
> 
> while (1) {
> redraw();
> }
> 

Yes, this is a typical example of an essentially broken application.

> The code will block to wait buffer release event  if there is no free
> buffer. But if display->last_error happen, the wl_display_dispatch_queue()
> fail too. Does the application use the wl_display_flush() right?

The bug is more likely that the application is flooding the compositor,
too rarely waiting for anything. This has high chances of filling up
both the kernel socket buffer and libwayland-client's send buffer,
which is fatal to the connection, leading to at least a disconnect. It
can also lead to abort() currently, though there is interest to fix
that to just disconnect.

The example you gave does not actually block on anything. Are you sure
your application is regularly waiting for compositor events?

You might also want to read the recent thread:
https://lists.freedesktop.org/archives/wayland-devel/2018-June/038437.html

The client is responsible for checking the return value of
wl_display_flush(), and poll the Wayland fd for writable if the
function indicates an EAGAIN condition. While flush fails, the client
must restrain from sending any further requests as those may overflow
the buffers and cause a disconnect.


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/20180621/08314156/attachment.sig>