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

Lloyd Pique lpique at google.com
Wed Jun 20 04:06:15 UTC 2018


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.

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.

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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180619/8c580c8a/attachment.html>


More information about the wayland-devel mailing list