-
Notifications
You must be signed in to change notification settings - Fork 12.3k
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
Tracking Issue for tcp_linger
#88494
Comments
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; }
} |
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 ? |
Feature gate:
#![feature(tcp_linger)]
This is a tracking issue for the
TcpStream::linger
andTcpStream::set_linger
methods that get/set theSO_LINGER
option on the socket. Behavior works as expected on both Unix and Windows.Public API
Steps / History
TcpStream::set_linger
andTcpStream::linger
#88495Unresolved Questions
The text was updated successfully, but these errors were encountered: