eventfd is documented reasonably well in its man page. The current implementation in Miri is incomplete, doesn't have tests (it is only indirect exercised via the tokio MVP test but that's not a good way to test a specific low-level API), and is partially wrong.
It is incomplete in that read is not implemented, which means they can't actually be used to do anything.
That's also where EFD_NONBLOCK would come in.
It is partially wrong in that
write panics in all sorts of situations that should be handled gracefullydup creates a new independent event object, rather than a second FD that refers to the same event object
Work on this should IMO follow the proposed "project" process.
eventfdis documented reasonably well in its man page. The current implementation in Miri is incomplete, doesn't have tests (it is only indirect exercised via the tokio MVP test but that's not a good way to test a specific low-level API), and is partially wrong.It is incomplete in that
readis not implemented, which means they can't actually be used to do anything.That's also where EFD_NONBLOCK would come in.
It is partially wrong in that
writepanics in all sorts of situations that should be handled gracefullydupcreates a new independent event object, rather than a second FD that refers to the same event objectWork on this should IMO follow the proposed "project" process.