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

[Pekka Paalanen]

On Tue, 19 Jun 2018 21:06:15 -0700
Lloyd Pique <lpique at google.com> wrote:

> I did think of one more option to avoid the dup() abort.
> 
> - Open MAX_FDS_OUT to reserve a pool of fds (open /dev/nul or something
> innocuous)
> - Whenever the core client needs to dup a caller fd, use dup2/dup3 on an fd
> in the pool
> - Whenever the core client is done with the caller fd, use dup2/dup3 to
> release it and point it back at something innocuous.

Sorry, I don't think we are that desperate. :-)

I think we have established there probably isn't any reasonable way to
recover from dup() failure without disconnecting.

> Separately, as my client is a service level nested server, I could
> effectively configure it with setrlimit, and bump up the pool to the 1000
> fds to fill the entire ring buffer. That would work, but may not be a
> general solution for simpler clients, especially since the default limit is
> only 1024.

Very rare client would even be sending tons of fds. Usually a client
has few buffers per wl_surface, and fds are sent when creating
wl_buffers but not when re-using them. A window being continuously
resized would be the usual cause of sending fds constantly since buffer
resize often implies allocation. Even then, the rate would be limited
to one buffer per display refresh and surface for a well-behaved client.

Outside buffers, the use of fds is very rare in general. This is why
you are the first to seriously hit and investigate this problem. You
have probably the first app that is hitting the 28 fds limit, at least
I don't recall hearing about such before.

Therefore I claim that most clients return to their main event loop to
sleep well before they have queued even a dozen fds. Your Wayland
client could have its rlimit raised, and sounds like it should have in
any case. This is why I think the dup() failure does not really need a
recovery mechanism that would keep the Wayland connection alive.


Thanks,
pq

> If blocking is out, maybe the only thing I can do is add an option to
> configure the amount of fd's the core will reserve/enqueue? However, while
> it isn't a dangerous option, it also wouldn't just necessarily with a
> default of 28, without the developer knowing what larger value to set.
> 
> (To make it clear, I'm thinking through this final issue with the fd limit
> as best I can before I go ahead and revise my patch)
> 
> - Lloyd

-------------- 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/1e3dd7f7/attachment.sig>