search

rust-lang / miri

An interpreter for Rust's mid-level intermediate representation
Apache License 2.0
4.65k stars 348 forks source link

Add test for epoll #4033

Closed tiif closed 2 weeks ago

tiif commented 2 weeks ago

I forgot how the implementation works and was wondering how the assumption here is being upheld. So I wrote a test.

https://github.com/rust-lang/miri/blob/9d9da34f49562bbe78e09213ee6e8aa9b9db1cce/src/shims/unix/linux/epoll.rs#L541-L542

This is mainly written for me to verify if it actually works, so it is perfectly ok to not merge this.

tiif commented 2 weeks ago

@rustbot ready

RalfJung commented 1 week ago

Don't our existing tests already cover this case? I added a comment along those lines:

https://github.com/rust-lang/miri/blob/9e0205daee66307a2ac7793d449e934d7c6de4e9/tests/pass-dep/libc/libc-epoll-no-blocking.rs#L83-L84

The test is not very clear about the fact that that is what it tests, though.

RalfJung commented 1 week ago

Ah I guess this is a different aspect of "edge semantics".

tiif commented 6 days ago

Ah I guess this is a different aspect of "edge semantics".

Yup it's different. The non-blocking test checks "if no event occurs between two epoll_wait calls, we should not receive any notification during the second epoll_wait". The test in this PR checks "if multiple threads are blocking on the same epoll fd, a single notification on that epoll fd should wake up only one thread (the alternative would be waking up all threads, i.e. thundering herd behaviour )"