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

[Pekka Paalanen]

On Tue, 19 Jun 2018 13:23:44 -0700
Lloyd Pique <lpique at google.com> wrote:

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

The purpose of dup() is to allow the program close() the fd
immediately after calling a message sending function. We also do not
want to flush on every request, that's the whole reason a buffer even
exists.

Or do you propose that dup() failure would trigger a flush and retry?

A flush could free more fd space, but yeah, implicit flushes always
have the issue with failing.

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

Yes, there is a reason why message sending functions do not return a
status. It would be too hard to deal with aside from mostly ignoring it.

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

Let's deal with one thing at a time. I'd suggest getting the full
fds_out capacity into use first, and see where that gets us. The second
step would be the "flush recommended" API.

If dup() becomes the next problem, we'll think about that then.
However, I'm still not convinced that dup() failure should be
recoverable without disconnecting. A program shouldn't be operating
near the fd space cap, like it shouldn't be operating near stack
exhaustion either. It comes down to what we would consider reasonable
in both behaviour and error recovery.


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/80f7dc69/attachment-0001.sig>