Potential race condition for edge-triggered platforms in AsyncFd

[jw4js]

On some platforms, the readiness detecting mechanism relies on edge-triggered notifications. This means that the OS will only notify Tokio when the file descriptor transitions from not-ready to ready. For this to work you should first try to read or write and only poll for readiness if that fails with an error of std::io::ErrorKind::WouldBlock.

This is from the documentation for AsyncFd. Does this not run into a race condition if the following happens:

• Read is attempted, returns EWOULDBLOCK
• File descriptor becomes ready
• await on readable()

?

Since there is no transition from not-ready to ready after the await starts, the program waits indefinitely.

It's possible I'm misunderstanding something about this, would appreciate if someone sheds some light on this.

[Darksonn]

We have thought of this of course :)

Tokio uses a counter for the number of readiness events to avoid this race condition. To perform a read, it does these things:

1. Read the value of the counter.
2. Perform the read.
3. If the read returns EWOULDBLOCK, store the value of the counter from before the read.

When you call .await on readable(), it will wait until the readiness counter becomes larger than the value stored in step 3. If it's already larger, then it returns immediately. This means that any readiness event that happened after step 1 (so including events during step 2), will be enough for readable().await to return immediately.