Tracking Issue for tcp_deferaccept

[devnexen]

Feature gate: #![feature(tcp_deferaccept)]

This is a tracking issue for the tcp_deferaccept feature.

It allows for the current socket to delay the acceptance of a connection until data is available to be read

Public API

It expands the existing Linux's TcpStreamExt trait with

pub trait TcpStreamExt: Sealed{
  fn deferaccept(&self) -> io::Result<Duration>;
  fn set_deferaccept(&self, accept: Duration) -> io::Result<()>;
}

This feature directly translates to the underlying native Linux TCP_DEFER_ACCEPT tcp(7) option.

Implementation history

• os::net: expanding TcpStreamExt for Linux with tcp_deferaccept. #119636
• std::net: update tcp deferaccept delay type to Duration. #140482

[joshtriplett]

We talked about this in today's @rust-lang/libs-api meeting.

Several people felt like this should accept a Duration instead of a u32 number of seconds. That would allow for the future possibility of an interface that allows sub-second granularity, without having to add a new function.

If we do that, then we should document that we round the Duration down to the nearest second.

[JohnTitor]

The above comment is now resolved and I guess no blockers now? Could we start FCP to stabilize this? @rust-lang/libs-api

[Amanieu]

@rfcbot merge libs-api

[rust-rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.