-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backend: Handle EINTR
, partial writes when using sendmsg
#647
base: master
Are you sure you want to change the base?
Conversation
Correct use of `sendmsg`/`write`, or any such call needs to handle `EINTR`, and partial writes. Even if this may be rare. `wl_connection_flush` in libwayland handles these things. A couple things still seem wrong: * If there's a limit to how many fds can be send in one message, that needs to be handled. I don't know if POSIX defines that anywhere. * Using a `Vec<u32>` for the buffer here may be problematic. What if a partial write writes a number of bytes that isn't a multiple of 4? There is in general no guarantee that won't happen.
I don't think this one will be an issue, both libwayland and wayland-backend puts a hard limit on the number of FD that can be sent in a single message at 28, though we might need to check that the current logic does actually respect this limit, I'm not 100% sure...
That a good point, we should change that. |
If it's buffering data and file descriptors from multiple messages, before sending on a flush, it could have more fds than the limit for a single message, right? |
Ah sorry, the limit of 28 fds applies to unix datagrams, not wayland messages |
Ah, looking at https://www.man7.org/linux/man-pages/man7/unix.7.html:
It looks like It seems quite unlikely that 253 file descriptors would be in queued messages in wayland-rs before the connection is flushed, so this is unlikely to be a problem in practice. But it would be good to make sure it works correctly anyway. Not a major priority though. |
The constraint is more that the receiving side will not expect more than 28 FDs in a single unix datagram, so sending more than 28 will cause some FD to be lost (recvmsg will drop them if you don't provide a large enough buffer to receive them). |
Wayland uses But I'm not sure exactly how that works on the receiving end. When a |
Right, good point. Well, if I believe |
Correct use of
sendmsg
/write
, or any such call needs to handleEINTR
, and partial writes. Even if this may be rare.wl_connection_flush
in libwayland handles these things.A couple things still seem wrong:
Vec<u32>
for the buffer here may be problematic. What if a partial write writes a number of bytes that isn't a multiple of 4? There is in general no guarantee that won't happen.