Tracking Issue for tcp_linger

[ibraheemdev]

Feature gate: #![feature(tcp_linger)]

This is a tracking issue for the TcpStream::linger and TcpStream::set_linger methods that get/set the SO_LINGER option on the socket. Behavior works as expected on both Unix and Windows.

Public API

impl TcpStream {
    pub fn set_linger(&self, linger: Option<Duration>) -> io::Result<()>;
    pub fn linger(&self) -> io::Result<Option<Duration>>;
}

Steps / History

• Implementation: Add TcpStream::set_linger and TcpStream::linger #88495
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should enabling lingering and setting the duration be split out into two operations?

[ibraheemdev]

Similar to the TCP keepalive, there are actually two operations here. Enabling lingering, and setting the duration. Right now we use an option for both, but we might want to separate these out. For reference, C# has the following API:

public class LingerOption {
   public bool Enabled { get; set; }
   public int LingerTime { get; set; }
}

public class TcpClient {
    // ...
    public LingerOption? LingerState { get; set; }
}

[anisse]

Similar to the TCP keepalive, there are actually two operations here. Enabling lingering, and setting the duration. Right now we use an option for both, but we might want to separate these out.

At least on Linux, this wouldn't match the underlying syscall behavior. The setsockopt SO_LINGER needs a duration when linger is enabled. Otherwise what would be the default value ? Would enabling mean two syscalls ? I think the way the nightly rust api is currently designed is a better match to linux semantics.

Edit: apparently the windows implementation uses libc's setsockopt too ? So it also matches the windows semantics ?