[PATCH] client: Allow send error recovery without an abort

[Lloyd Pique]

Hi Pekka,

- ABI to query a "flush recommended" flag; This flag would be set when
>   the soft-buffer is at least half-full, and cleared when it drops
>   to... below half? empty?


This sounds reasonable, I'm happy to incorporate this first bit into my
patch, but .....


> - When a client is doing lots of request sending without returning to
>   its main loop which would call wl_display_flush() anyway, it can
>   query the flag to see if it needs to flush.


> - If flush ever fails, stop all request sending, poll for writable and
>   try again. How to do this is left for the application. Most
>   importantly, the application could set some state and return to its
>   main event loop to do other stuff in the mean while.
>

> You're right that this wouldn't help an application that sends requests
> from multiple threads a lot. They would need to be checking the flag
> practically for every few requests, but at least that would be cheaper
> than calling wl_display_flush() outright.
>


[...]



Can you think of any way to recover from dupfd failure without
> disconnecting?


There are only two ways I can think of to recover from the dupfd failure:

1) Don't dup(). The purpose of it is to enqueue fds in the fds_out ring
buffer across multiple send calls. If instead a send call that had fd's did
an immediate flush, there would be no need for the dupe. The downside is
that the caller doesn't get a chance to do its wl_display_flush() under
conditions where it can do a wait.
2) Add a new "send-error" flag, breaking existing code, and requiring the
client to check after every send call and somehow do its own recovery and
retry the send calls.

I don't think anyone would want the second, except maybe as some
fundamental redesign that new clients were written anew for.

The first might actually be acceptable to me in practice.

Assuming the one wl_abort() after the call to wl_closure_send() becomes a
display_fatal_error(), and an EAGAIN here is converted to an EPIPE or other
fatal error, I don't think I will see EAGAIN very often if ever.

As you said, the kernel buffers are large. I don't know if that also
applies to fd's, but I would expect it has much larger limits there too.

But that is based on what I'm think I'm running into. Another client might
not want that.

I'm out of immediate ideas. What do you think?

- Lloyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180619/ccc1148c/attachment-0001.html>