Closed ZoeS17 closed 5 months ago
:umbrella: The latest upstream changes (presumably #3441) made this pull request unmergeable. Please resolve the merge conflicts.
IOW, I think this should follow the proposed "project" process: https://github.com/rust-lang/miri/issues/3443. We're happy to help you through that process! This is probably best done on Zulip, but you can also open an issue dedicated to the project and we can discuss there.
I have opened an issue to track this: https://github.com/rust-lang/miri/issues/3449.
I think blocking sockets are actually highly non-trivial to implement.
So to be clear I think before any implementation work is done, we need a clear description of which part of the socket API is intended to be implemented (TCP/UDP/..., blocking/non-blocking, which shims are involved). And since this will be non-trivial to implement, we also need a description of what the implementation plan is -- which new state is needed in Miri, how do we handle waking up the right threads when the sockets they are blocked on get ready, things like that. I laid out some of the complications in https://github.com/rust-lang/miri/issues/3449.
Adding sockets is not an easy project. And with projects of this scale it's not a good idea to just go implement something -- that has a pretty high risk that we'll ask you to re-write it entirely as we see flaws with the fundamental structure of the approach, and it also makes review much harder when we have to reverse engineer the high-level approach from the code.
@ZoeS17 what is your goal with this PR? Is there a motivation for wanting to land just the socket
shim without actually supporting sockets at all?
:umbrella: The latest upstream changes (presumably #3451) made this pull request unmergeable. Please resolve the merge conflicts.
Adding sockets is not an easy project. And with projects of this scale it's not a good idea to just go implement something -- that has a pretty high risk that we'll ask you to re-write it entirely as we see flaws with the fundamental structure of the approach, and it also makes review much harder when we have to reverse engineer the high-level approach from the code.
Agreed.
what is your goal with this PR? Is there a motivation for wanting to land just the
socket
shim without actually supporting sockets at all?
My intent was originally to land this as a shim without supporting sockets at all but given what has been said in the #3449 I agree that it seems foolish to continue as a "hollow" implementation. I originally come upon the desire to pick up this work because I was attempting to run miri against a program I was building that utilizes sockets to connect to IRC. Since obviously that needs a deeper implementation then I originally understood I'm up for closing this PR with an understanding that I'm willing to admit I may be out of my depth here.
I originally come upon the desire to pick up this work because I was attempting to run miri against a program I was building that utilizes sockets to connect to IRC.
Ah, yes makes sense. I'm afraid that's a pretty hard problem and quite far off currently, unfortunately.
I'll close this PR then. Thanks anyway!
I vaguely followed socketpair as to implementation details. I attempted to make a test too but there's not exactly a good way, that I can figure out, besides simply checking that an file descriptor gets made. I dd so for both the libc crate and the version I implemented.
Free feel to ask question and/or adjust if needed.