From 8005eedf41669fdf672ccd9332c195fdfa4702eb Mon Sep 17 00:00:00 2001 From: Johnathan Corgan Date: Sat, 22 Aug 2026 13:42:28 +0100 Subject: [PATCH] Record what the FreeBSD run measured, since the comments said it was unmeasured The fix shipped with its evidence stated honestly as read-from-source and inferred-from-a-log, because nothing had run on FreeBSD. The job has now run green and the three probes that shipped with it all passed, so those comments understate what is known. A SOCK_SEQPACKET pair on the FreeBSD 15.1 image does not keep message boundaries and drops a zero-length message rather than delivering it. Both were predicted from the kernel source and both now have a measurement agreeing with the prediction. The open question the port rested on is answered too, and favourably: a closed SOCK_DGRAM peer is detectable on FreeBSD, so a flow's end of file comes from the descriptor there as it does on Darwin, and the line-protocol fallback that a negative result would have forced is not needed. --- src/native/dgram_probe.rs | 4 +++- src/native/seqpacket.rs | 13 +++++++------ 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/src/native/dgram_probe.rs b/src/native/dgram_probe.rs index b0d1b41b..6e36952b 100644 --- a/src/native/dgram_probe.rs +++ b/src/native/dgram_probe.rs @@ -325,7 +325,9 @@ fn an_empty_datagram_queued_before_the_close_is_not_read_as_the_close() { /// The open question this platform's arm of [`super::seqpacket`] rests on, and /// the counterpart of [`darwin_reports_a_closed_dgram_peer_somehow`]. The three /// kernels do three different things: Linux reports nothing at all, Darwin -/// reports `ECONNRESET`, and FreeBSD has not been measured. `recv_once` accepts +/// reports `ECONNRESET`, and FreeBSD does signal it — this probe passed on the +/// 15.1 CI image on 2026-08-22, so the flow's end of file can come from the +/// descriptor there and no line-protocol fallback is needed. `recv_once` accepts /// either `ECONNRESET` or a zero-byte read plus `POLLHUP`, so either signal is /// enough and the assertion does not care which. /// diff --git a/src/native/seqpacket.rs b/src/native/seqpacket.rs index 514222a1..f83cd6c3 100644 --- a/src/native/seqpacket.rs +++ b/src/native/seqpacket.rs @@ -16,12 +16,13 @@ //! is not an atomic-record socket: `seqpacketproto` carries no `PR_ATOMIC` and //! shares its send and receive handlers with `SOCK_STREAM`, so consecutive //! messages coalesce and a zero-length message is queued nowhere and delivered -//! never. **This was read out of the FreeBSD kernel source and inferred from a -//! CI log; nobody has run it on FreeBSD.** What was observed is a CI run in -//! which the zero-length-message test hung until the job was killed and five -//! boundary tests failed within 360 ms, which is the shape the source predicts. -//! The probes in [`super::dgram_probe`] are what would turn that into a -//! measurement, and they have not been run on FreeBSD either. +//! never. **Measured on the FreeBSD 15.1 CI image on 2026-08-22**, by the two +//! probes in [`super::dgram_probe`] named for it: a `SOCK_SEQPACKET` pair there +//! does not keep message boundaries, and it drops a zero-length message instead +//! of delivering it. The reading of the kernel source came first and the +//! measurement agreed with it; before that run the mechanism was inferred from +//! a CI log in which the zero-length-message test hung until the job was killed +//! and five boundary tests failed within 360 ms. //! Everything else this module needs works on both: `SCM_RIGHTS` is supported, //! `AsyncFd` is backed by kqueue, and a connected `SOCK_DGRAM` pair keeps //! message boundaries and delivers an empty datagram, which `SOCK_SEQPACKET`