Skip to content
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

Implement epoll shim #3712

Merged
merged 1 commit into from
Aug 14, 2024
Merged

Implement epoll shim #3712

merged 1 commit into from
Aug 14, 2024

Conversation

tiif
Copy link
Contributor

@tiif tiif commented Jun 26, 2024

This PR:

@tiif
Copy link
Contributor Author

tiif commented Jun 26, 2024

@rustbot author

@rustbot rustbot added the S-waiting-on-author Status: Waiting for the PR author to address review comments label Jun 26, 2024
src/shims/unix/socket.rs Outdated Show resolved Hide resolved
src/shims/unix/socket.rs Outdated Show resolved Hide resolved
src/shims/unix/fd.rs Outdated Show resolved Hide resolved
src/shims/unix/fd.rs Outdated Show resolved Hide resolved
src/shims/unix/socket.rs Outdated Show resolved Hide resolved
src/shims/unix/socket.rs Outdated Show resolved Hide resolved
src/shims/unix/socket.rs Outdated Show resolved Hide resolved
src/shims/unix/socket.rs Outdated Show resolved Hide resolved
src/shims/unix/fd.rs Outdated Show resolved Hide resolved
src/shims/unix/linux/epoll.rs Outdated Show resolved Hide resolved
@oli-obk
Copy link
Contributor

oli-obk commented Aug 8, 2024

Maybe you need to rebase

@tiif
Copy link
Contributor Author

tiif commented Aug 9, 2024

80d407e is an attempt to pass in FileDescriptionRef to check_and_update_readiness, but it ICEs for eventfd test. I haven't fully understood why it happens, but my current guess is it forms a kind of circular reference because we are doing this:

  1. FileDescription::read calls check_and_update_readiness
  2. Inside check_and_update_readiness, we borrow_mut the file description again.

I am not sure if it is possible to make it work, but I am going to revert this an try to pass FdId to read/write first.

ICE error message
thread 'rustc' panicked at src/shims/unix/fd.rs:236:45:
already borrowed: BorrowMutError
stack backtrace:
   0:     0x74cf3217ddd5 - std::backtrace_rs::backtrace::libunwind::trace::he59335385543b4e7
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:116:5
   1:     0x74cf3217ddd5 - std::backtrace_rs::backtrace::trace_unsynchronized::h7c84e90889d9a1bb
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x74cf3217ddd5 - std::sys::backtrace::_print_fmt::h4d4fd356397c3378
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/sys/backtrace.rs:66:9
   3:     0x74cf3217ddd5 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::hde110f186e471219
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/sys/backtrace.rs:39:26
   4:     0x74cf321cecfb - core::fmt::rt::Argument::fmt::h08e1f010bbba14d0
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/fmt/rt.rs:173:76
   5:     0x74cf321cecfb - core::fmt::write::hb225859127e7765b
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/fmt/mod.rs:1178:21
   6:     0x74cf3217261f - std::io::Write::write_fmt::h210b8145a2e5358b
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/io/mod.rs:1823:15
   7:     0x74cf32180671 - std::sys::backtrace::BacktraceLock::print::h2cba555a5ecfba6e
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/sys/backtrace.rs:42:9
   8:     0x74cf32180671 - std::panicking::default_hook::{{closure}}::h908da943d0764776
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:266:22
   9:     0x74cf3218034c - std::panicking::default_hook::h78057f076c8a8ad8
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:293:9
  10:     0x74cf35644af9 - std[47b6bda5310033f4]::panicking::update_hook::<alloc[8f32396a97214ba5]::boxed::Box<rustc_driver_impl[bad6c552c0296adc]::install_ice_hook::{closure#0}>>::{closure#0}
  11:     0x74cf3218103f - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h0f07d18a9e7ba2b2
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/alloc/src/boxed.rs:2162:9
  12:     0x74cf3218103f - std::panicking::rust_panic_with_hook::h8cf4d1eff41758c5
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:805:13
  13:     0x74cf32180c67 - std::panicking::begin_panic_handler::{{closure}}::hc381813fafeb3969
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:671:13
  14:     0x74cf3217e299 - std::sys::backtrace::__rust_end_short_backtrace::h688ac9f52e29476a
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/sys/backtrace.rs:170:18
  15:     0x74cf321808f4 - rust_begin_unwind
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:662:5
  16:     0x74cf321cb2c3 - core::panicking::panic_fmt::hf0000f31cd37d561
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/panicking.rs:74:14
  17:     0x74cf321c8103 - core::cell::panic_already_borrowed::hce2c3af5b8e750d8
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/cell.rs:787:5
  18:     0x61f340c419d0 - core::cell::RefCell<T>::borrow_mut::hc8491909e95877c9
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/cell.rs:1078:25
  19:     0x61f340c419d0 - miri::shims::unix::fd::FileDescriptionRef::borrow_mut::ha6b56c880ba131fa
                               at /home/byt/Documents/miri/src/shims/unix/fd.rs:236:21
  20:     0x61f340c419d0 - miri::shims::unix::linux::epoll::EvalContextExt::check_and_update_readiness::hb3bfc5ed26545b74
                               at /home/byt/Documents/miri/src/shims/unix/linux/epoll.rs:449:38
  21:     0x61f340ce34db - <miri::shims::unix::linux::eventfd::Event as miri::shims::unix::fd::FileDescription>::read::h95373e54e5d409b5
                               at /home/byt/Documents/miri/src/shims/unix/linux/eventfd.rs:97:13
  22:     0x61f340c2f14e - miri::shims::unix::fd::EvalContextExt::read::h6387a12f7f75f421
                               at /home/byt/Documents/miri/src/shims/unix/fd.rs:576:21
  23:     0x61f340c2481d - miri::shims::unix::foreign_items::EvalContextExt::emulate_foreign_item_inner::hdf8f4f8957eade9c
                               at /home/byt/Documents/miri/src/shims/unix/foreign_items.rs:95:30
  24:     0x61f340c6f090 - miri::shims::foreign_items::EvalContextExtPriv::emulate_foreign_item_inner::hf33eb5da0886c6d4
                               at /home/byt/Documents/miri/src/shims/foreign_items.rs:952:25
  25:     0x61f340c6b84a - miri::shims::foreign_items::EvalContextExt::emulate_foreign_item::hb3d83275619b51de
                               at /home/byt/Documents/miri/src/shims/foreign_items.rs:70:15
  26:     0x61f340bbd4b5 - <miri::machine::MiriMachine as rustc_const_eval::interpret::machine::Machine>::find_mir_or_eval_fn::h12f89890355ac47f
                               at /home/byt/Documents/miri/src/machine.rs:984:20
  27:     0x61f340bbd4b5 - rustc_const_eval::interpret::terminator::<impl rustc_const_eval::interpret::eval_context::InterpCx<M>>::eval_fn_call::h5139575d80e9aa6a
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_const_eval/src/interpret/terminator.rs:621:46
  28:     0x61f340bfb821 - rustc_const_eval::interpret::terminator::<impl rustc_const_eval::interpret::eval_context::InterpCx<M>>::eval_terminator::h282a1bcffca2f0eb
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_const_eval/src/interpret/terminator.rs:133:17
  29:     0x61f340bfb821 - rustc_const_eval::interpret::step::<impl rustc_const_eval::interpret::eval_context::InterpCx<M>>::terminator::hc66a0ed88e387be6
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_const_eval/src/interpret/step.rs:383:9
  30:     0x61f340bfb821 - rustc_const_eval::interpret::step::<impl rustc_const_eval::interpret::eval_context::InterpCx<M>>::step::h71c560bbe4128a31
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_const_eval/src/interpret/step.rs:51:9
  31:     0x61f340bfb821 - miri::concurrency::thread::EvalContextExt::run_threads::h4b8d54facb86cd82
                               at /home/byt/Documents/miri/src/concurrency/thread.rs:1197:25
  32:     0x61f340b1917e - miri::eval::eval_entry::{{closure}}::h0a868308d84278ae
                               at /home/byt/Documents/miri/src/eval.rs:445:49
  33:     0x61f340b1917e - core::ops::function::FnOnce::call_once::h8458d316094a605b
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/ops/function.rs:250:5
  34:     0x61f340b1917e - <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h6dcd64c25e38427b
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/core/src/panic/unwind_safe.rs:272:9
  35:     0x61f340b1917e - std::panicking::try::do_call::h2a8bc7bd42ad739a
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:554:40
  36:     0x61f340b1917e - std::panicking::try::h3e09c3f57cb7121b
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panicking.rs:518:19
  37:     0x61f340b1917e - std::panic::catch_unwind::hd082b45a3f557876
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/panic.rs:345:14
  38:     0x61f340b1917e - miri::eval::eval_entry::h9606b7c20aa35ad7
                               at /home/byt/Documents/miri/src/eval.rs:445:9
  39:     0x61f340a8e349 - <miri::MiriCompilerCalls as rustc_driver_impl::Callbacks>::after_analysis::{{closure}}::h4ed3975824bb13a7
                               at /home/byt/Documents/miri/src/bin/miri.rs:114:40
  40:     0x61f340a8e349 - rustc_middle::ty::context::GlobalCtxt::enter::{{closure}}::h993e552016cccdcd
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_middle/src/ty/context.rs:1331:37
  41:     0x61f340a8e349 - rustc_middle::ty::context::tls::enter_context::{{closure}}::h520a6e8d4a69a77c
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_middle/src/ty/context/tls.rs:82:9
  42:     0x61f340a8e349 - std::thread::local::LocalKey<T>::try_with::h821dca7f769b72a2
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/thread/local.rs:283:12
  43:     0x61f340a8e349 - std::thread::local::LocalKey<T>::with::h577858e84b543777
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/thread/local.rs:260:9
  44:     0x61f340a8e349 - rustc_middle::ty::context::tls::enter_context::h359a4877bd951015
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_middle/src/ty/context/tls.rs:79:9
  45:     0x61f340a8e349 - rustc_middle::ty::context::GlobalCtxt::enter::h9aabebea09eac648
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_middle/src/ty/context.rs:1331:9
  46:     0x61f340a92b19 - rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>::enter::h6667d8429b7307c4
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/compiler/rustc_interface/src/queries.rs:65:9
  47:     0x61f340a92b19 - <miri::MiriCompilerCalls as rustc_driver_impl::Callbacks>::after_analysis::h4dd7be76087912d2
                               at /home/byt/Documents/miri/src/bin/miri.rs:74:9
  48:     0x74cf379f5dce - rustc_interface[2879afccd290b137]::interface::run_compiler::<core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>, rustc_driver_impl[bad6c552c0296adc]::run_compiler::{closure#0}>::{closure#1}
  49:     0x74cf379db709 - std[47b6bda5310033f4]::sys::backtrace::__rust_begin_short_backtrace::<rustc_interface[2879afccd290b137]::util::run_in_thread_with_globals<rustc_interface[2879afccd290b137]::util::run_in_thread_pool_with_globals<rustc_interface[2879afccd290b137]::interface::run_compiler<core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>, rustc_driver_impl[bad6c552c0296adc]::run_compiler::{closure#0}>::{closure#1}, core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>>::{closure#0}, core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>>
  50:     0x74cf379db4ba - <<std[47b6bda5310033f4]::thread::Builder>::spawn_unchecked_<rustc_interface[2879afccd290b137]::util::run_in_thread_with_globals<rustc_interface[2879afccd290b137]::util::run_in_thread_pool_with_globals<rustc_interface[2879afccd290b137]::interface::run_compiler<core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>, rustc_driver_impl[bad6c552c0296adc]::run_compiler::{closure#0}>::{closure#1}, core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>>::{closure#0}, core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[88f6a1db45837a48]::result::Result<(), rustc_span[29f3c8e11ce55b6c]::ErrorGuaranteed>>::{closure#1} as core[88f6a1db45837a48]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  51:     0x74cf3218afbb - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hc2643f81a499fd0c
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/alloc/src/boxed.rs:2148:9
  52:     0x74cf3218afbb - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::ha8d56f3a1fc33872
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/alloc/src/boxed.rs:2148:9
  53:     0x74cf3218afbb - std::sys::pal::unix::thread::Thread::new::thread_start::h9d7a26a6515c8c04
                               at /rustc/dba8e2d2c2890a8b9e88cbf4855ac5711337946c/library/std/src/sys/pal/unix/thread.rs:105:17
  54:     0x74cf31e94ac3 - start_thread
                               at ./nptl/pthread_create.c:442:8
  55:     0x74cf31f26850 - __GI___clone3
                               at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
  56:                0x0 - <unknown>

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/miri/issues/new

note: please make sure that you have updated to the latest nightly

note: please attach the file at `/home/byt/Documents/miri/rustc-ice-2024-08-09T07_29_32-2219326.txt` to your bug report

query stack during panic:
end of query stack

Miri caused an ICE during evaluation. Here's the interpreter backtrace at the time of the panic:
note: the place in the program where the ICE was triggered
   --> ./tests/pass-dep/libc/libc-epoll.rs:478:29
    |
478 |     let res: i32 = unsafe { libc::read(fd, buf.as_mut_ptr().cast(), 8).try_into().unwrap() };
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: BACKTRACE:
    = note: inside `test_event_overwrite` at ./tests/pass-dep/libc/libc-epoll.rs:478:29: 478:71
note: inside `main`
   --> ./tests/pass-dep/libc/libc-epoll.rs:8:5
    |
8   |     test_event_overwrite();
    |     ^^^^^^^^^^^^^^^^^^^^^^
    = note: inside `<fn() as std::ops::FnOnce<()>>::call_once - shim(fn())` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5: 250:71
    = note: inside `std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:154:18: 154:21
    = note: inside closure at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/rt.rs:164:18: 164:75
    = note: inside `std::ops::function::impls::<impl std::ops::FnOnce<()> for &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>::call_once` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/core/src/ops/function.rs:284:13: 284:31
    = note: inside `std::panicking::r#try::do_call::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panicking.rs:554:40: 554:43
    = note: inside `std::panicking::r#try::<i32, &dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panicking.rs:518:19: 518:88
    = note: inside `std::panic::catch_unwind::<&dyn std::ops::Fn() -> i32 + std::marker::Sync + std::panic::RefUnwindSafe, i32>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panic.rs:345:14: 345:33
    = note: inside closure at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/rt.rs:143:48: 143:73
    = note: inside `std::panicking::r#try::do_call::<{closure@std::rt::lang_start_internal::{closure#2}}, isize>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panicking.rs:554:40: 554:43
    = note: inside `std::panicking::r#try::<isize, {closure@std::rt::lang_start_internal::{closure#2}}>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panicking.rs:518:19: 518:88
    = note: inside `std::panic::catch_unwind::<{closure@std::rt::lang_start_internal::{closure#2}}, isize>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/panic.rs:345:14: 345:33
    = note: inside `std::rt::lang_start_internal` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/rt.rs:143:20: 143:98
    = note: inside `std::rt::lang_start::<()>` at /home/byt/.rustup/toolchains/miri/lib/rustlib/src/rust/library/std/src/rt.rs:163:17: 168:6

error: test failed, to rerun pass `--test ui`

@@ -153,7 +150,7 @@ impl FileDescription for Event {
// When any of the event happened, we check and update the status of all supported event
// types for current file description.
use crate::shims::unix::linux::epoll::EvalContextExt;
ecx.check_and_update_readiness(fd_ref)?;
ecx.check_and_update_readiness(self.id, || self.get_epoll_ready_events())?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here it is actually crucial that we access self.get_epoll_ready_events and do not get a second borrow of the RefCell for this FD... well that is tricky.

Please add a comment here explaining that. Also, please add a comment next to the version of check_and_update_readiness that takes a separate ID and closure and explain that this is an internal helper and should not usually be used.

I wonder if we should just say that we always call check_and_update_readiness on the FD that was read or written after each read or write... but that also feels like a hack. Or we could have the id inside the FD type for each FD, but that also gets annoying. This seems to be one of these rare cases where inheritance would actually be nice, since we could have a "base class" with the id field and each FD type just inherits that.

@tiif
Copy link
Contributor Author

tiif commented Aug 9, 2024

All the comments were addressed, this is ready for another round of review. ^^

src/shims/unix/socket.rs Outdated Show resolved Hide resolved
@tiif
Copy link
Contributor Author

tiif commented Aug 10, 2024

4812fa6 ensures that notification will be provided if read emptied the buffer.

Related discussion is in https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/epoll.20notification.20on.20socketpair.20write.20unblock

@RalfJung
Copy link
Member

RalfJung commented Aug 10, 2024

Do we really want to emulate this behavior? I think epoll totally permits us to wake up these threads even when there is just one byte of space available for writing.

If we do, I think we shouldn't use "empty" as the threshold. More like, if at least 1KiB can be written, or at least half the buffer can be written, or something like that. I wonder what threshold the real implementation uses, but I doubt it is "empty" since that risks starving the readers -- the goal here is presumably to keep a good balance between readers and writers, so "half the buffer" seems like the most naive option to me. This should come with a comment indicating that we do this to avoid waking up threads when they could only write a few bytes.

@tiif
Copy link
Contributor Author

tiif commented Aug 10, 2024

Do we really want to emulate this behavior? I think epoll totally permits us to wake up these threads even when there is just one byte of space available for writing.

I actually prefer to not emulate this behavior and instead provide epoll notification every time read is called, because as long as socketpair reads more than 0 bytes, it will became writable. For this particular behavior, no matter how we approach it, there will always be cases where our emulation differs from the real system, so we might as well just choose one that makes sense. In my opinion, spuriously waking up threads is better than letting the thread blocks due to lack of notification. But I am not sure if I have missed something—let me know if anyone thinks otherwise.

@RalfJung
Copy link
Member

I am completely fine with waking threads up immediately when there's just one byte writeable, even if the real implementation behaves differently for optimization reasons. There should be a comment in the code explaining that.

Not sure if @oli-obk has a preference either way.

@oli-obk
Copy link
Contributor

oli-obk commented Aug 10, 2024

I too prefer just notifying whenever anything becomes writable/readable, irrespective of the size.

@tiif
Copy link
Contributor Author

tiif commented Aug 11, 2024

Okay updated, thanks for helping figure this out!

@oli-obk
Copy link
Contributor

oli-obk commented Aug 14, 2024

bors r plus

@bors
Copy link
Contributor

bors commented Aug 14, 2024

📌 Commit 5702761 has been approved by oli-obk

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Aug 14, 2024

⌛ Testing commit 5702761 with merge cd5d255...

@bors
Copy link
Contributor

bors commented Aug 14, 2024

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing cd5d255 to master...

@bors bors merged commit cd5d255 into rust-lang:master Aug 14, 2024
8 checks passed
@tiif tiif deleted the feat/epoll branch August 15, 2024 09:03
}

// When read/write happened on one side of the socketpair, only the other side will be notified.
fn test_epoll_socketpair_special_case() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this a "special case"?
When an FD changes status, only that FD gets notified. That's completely normal.

Copy link
Contributor Author

@tiif tiif Aug 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this is a test case added when I realised that socketpair fd shouldn't notify itself, it should notify it's peer instead. This behaviour is different from eventfd . I think the name is fixed in your PR, thanks for that!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The behavior is the same as eventfd. It notifies the FD that changed status. Of course you have to check properly for each case which FDs change status. :)

)?;
num_of_events = num_of_events.checked_add(1).unwrap();
} else {
break;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this wrong? This means that we popped an event from the ready list, but we didn't store it to the output array. It just gets discarded entirely.

When fixing this, please make sure to also add a test for this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, thanks for catching this, it is currently fixed in #3818

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Waiting for a review to complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants