Problem:
- Many constructors are defined as `{}` rather than using the ` =
default` compiler-provided constructor.
- Some types provide an implicit conversion operator from `nullptr_t`
instead of requiring the caller to default construct. This violates
the C++ Core Guidelines suggestion to declare single-argument
constructors explicit
(https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c46-by-default-declare-single-argument-constructors-explicit).
Solution:
- Change default constructors to use the compiler-provided default
constructor.
- Remove implicit conversion operators from `nullptr_t` and change
usage to enforce type consistency without conversion.
It is now possible to use the special IPC::File type in message arguments. In
C++, the type is nothing more than a wrapper over a file descriptor. But when
serializing/deserializing IPC::File arguments, LibIPC will use the sendfd/recvfd
kernel APIs instead of sending the integer inline.
This makes it quite convenient to pass files over IPC, and will allow us to
significantly tighten sandboxes in the future :^)
Closes https://github.com/SerenityOS/serenity/issues/3643
Since we're using byte streamed Unix sockets for the IPC protocols,
it's possible for the kernel to run out of socket buffer space with
a partial message near the end of the buffer.
Handle this situation in IPC::Connection by buffering the bytes of
what may be a partial message, and prepending them to the incoming
data next time we receive from the peer.
This fixes WindowServer asserting when a peer is spamming it hard.
Writing to the socket may trigger a close of the socket descriptor
if a disconnect was detected. We need to check if it is still valid
when waiting for a response after attempting to send a synchronous
message.
Fixes#3515
Because we're closing a file descriptor, we need to disable any
Notifier that is using it so that the EventLoop does not use invalid
file descriptors.
Fixes#3508
This patch introduces IPC::Connection which becomes the new base class
of ClientConnection and ServerConnection. Most of the functionality
has been hoisted up to the base class since almost all of it is useful
on both sides.
This gives us the ability to send synchronous messages in both
directions, which is needed for the WebContent server process.
Unlike other servers, WebContent does not mind blocking on a response
from its client.
