The various UnixStream implementations currently use a fixed size for the internal queue of file descriptors. This is current fixed at 2, though there is no particularly good reasons for this value.
The constrains on the size of the internal queue are as follows:
- it should be fairly small (at least by default) because it is used to calculate the size of an array allocated on the stack
- it should be the same on both sides of the "fd passing" (assuming both processes use this library)
The reason for the second constraint is to try to avoid the control data being truncated in the underlying call to recvmsg. This crate treats this occurrence as an error though the call to recvmsg implements it as a flag set on the msghdr structure passed as a parameter.
The second constraint also makes it a breaking change to increment the current fixed value across the board because you could end up with the sending side using a larger fixed value than the receiving side which would risk errors due to the control data being truncated on the underlying call to recvmsg.
The proposed (and non-breaking) change to allow users of the crate to have a larger (though still fixed) queue size is to make the various UnixStream implementations rely on a const generic parameter for the queue size (which would default to the current 2 to keep the change non-breaking). The proposed interface is:
pub const DEFAULT_FD_QUEUE_SIZE: usize = 2;
pub struct UnixStream<const N: usize = DEFAULT_FD_QUEUE_SIZE> { ... }
impl<const N:usize> UnixStream<N> {
pub const FD_QUEUE_SIZE: usize = N;
...
}It may be desirable to increase DEFAULT_FD_QUEUE_SIZE for the next major release but for now we would keep it at 2 to avoid a breaking change.
The various
UnixStreamimplementations currently use a fixed size for the internal queue of file descriptors. This is current fixed at 2, though there is no particularly good reasons for this value.The constrains on the size of the internal queue are as follows:
The reason for the second constraint is to try to avoid the control data being truncated in the underlying call to
recvmsg. This crate treats this occurrence as an error though the call torecvmsgimplements it as a flag set on themsghdrstructure passed as a parameter.The second constraint also makes it a breaking change to increment the current fixed value across the board because you could end up with the sending side using a larger fixed value than the receiving side which would risk errors due to the control data being truncated on the underlying call to
recvmsg.The proposed (and non-breaking) change to allow users of the crate to have a larger (though still fixed) queue size is to make the various
UnixStreamimplementations rely on a const generic parameter for the queue size (which would default to the current 2 to keep the change non-breaking). The proposed interface is:It may be desirable to increase
DEFAULT_FD_QUEUE_SIZEfor the next major release but for now we would keep it at 2 to avoid a breaking change.