On Tue, 19 Jun 2018 13:23:44 -0700 Lloyd Pique <[email protected]> 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
pgp_KVekAOlTB.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
