Closed RalfJung closed 4 months ago
Also the check here is bogus:
That should be flags & !(efd_cloexec | efd_nonblock | efd_semaphore) != 0
.
EDIT: but turns out we have the flags tokio needs.
dup creates a new independent event object, rather than a second FD that refers to the same event object
This should probably be fixed by implementing a proper notion of "file description", and making the file descriptor table a simple indirection for file descriptions. That would fix dup
for all FDs once and for all, and it will anyway be needed for epoll.
Hey @RalfJung I would like to give this a shot. May I just @rustbot claim
it?
Please coordinate with @oli-obk -- I saw something about a potential GSoC project for epoll support, and I assume this would be part of it.
cc @tiif
There's probably some parallel development that can be done, but the file descriptor table refactor is likely gonna block other work, so the earlier it is done the better.
I think it's probably for the best if I pick something simpler and isolated to start with. Thank you!
@rustbot claim
This hackmd contains the details for eventfd
implementation: https://hackmd.io/@tiif/rk9hlmP4R
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 gracefully(this got fixed in the mean time)dup
creates 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.