I added more test cases, and I realized some issues with file sock on both Windows and POSIX re: setting the nonblocking flag. I also added a wasi test case with zig-cc. Tomorrow I'll try to figure out if I can write another implementation in Rust and/or Go that actually invokes poll with multiple FDs (I am not sure the higher-level APIs actually do it)

EDIT: heh, I tried to write a simple example with gotip but I couldn't figure out how to make it call poll_oneoff 😬

// mainMixed is an explicit test of a blocking socket + stdin pipe.
func mainMixed() error {
	// Get a listener from the pre-opened file descriptor.
	// The listener is the first pre-open, with a file-descriptor of 3.
	f := os.NewFile(3, "")
	l, err := net.FileListener(f)
	defer f.Close()
	if err != nil {
		return err
	}
	defer l.Close()

	ch1 := make(chan error)
	ch2 := make(chan error)

	go func() {
		// Accept a connection
		conn, err := l.Accept()
		if err != nil {
			ch1 <- err
			return
		}
		defer conn.Close()

		// Do a blocking read of up to 32 bytes.
		// Note: the test should write: "wazero", so that's all we should read.
		var buf [32]byte
		n, err := conn.Read(buf[:])
		if err != nil {
			ch1 <- err
			return
		}
		fmt.Println(string(buf[:n]))
		close(ch1)
	}()

	go func() {
		b, err := io.ReadAll(os.Stdin)
		if err != nil {
			ch2 <- err
			return
		}
		os.Stdout.Write(b)
		close(ch2)
	}()
	err1 := <-ch1
	err2 := <-ch2
	if err1 != nil {
		return err1
	}
	if err2 != nil {
		return err2
	}
	return nil
}

Thanks for digging into the integration tests. This type of code/behavior is hard to pin down and exactly where the extra tests come in: to establish an "implementation quorum" please ping back when you feel things are settled or need a hand from someone else (even if technical over my head ;))

Ok, I added a test for gotip, and I have also figured out something for Rust (using tokio-rs/mio).

• I verified (with --hostlogging poll and also via debugger) they actually exercise poll_oneoff.
• The tests are not all the same but they are ~similar.
• The one that's actually most different is the one for gotip, because I can't tell if there is a straightforward way to make sure that all FDs are checked at once (spoiler: they aren't!), but at least it's checking more than one subscription at a time -- but they will all be in nonblocking mode, so it doesn't really follow the new code path, except for the timers.

I think at this point this is ready for review. It may still lack a bit of polish but your feedback is welcome.

EDIT: I have updated the top post.

oh, I was almost forgetting: while running make build.examples.zig-cc I noticed that the DWARF example was mistakingly being overwritten (I think the new build might have stripped the DWARF symbols) so we'll need to check that

100ms is a very long time, [...]
So, I'm wondering mainly why not use poll with a short timeout isn't used, if it is a defect or we are trying for the native side to use the fake clock.

100ms is completely arbitrary, I picked that because that's what I picked in the Windows impl (which now is irrelevant, since it is being invoked here with 0ms). We could certainly use a smaller delay, I am not an expert at all here.

IMHO I think that since timeout is a parameter of poll, in the Poll api, how timeout is implemented is up to the backend, which may choose to use a real or fake clock to sleep or a native poll. If in any case we are not able to trust the implementation of the poll timeout and avoiding using it for that reason, I would try to make it very clear why not, because in worst case it can feel like "spaghetti around a problem" to do externnal orchestration of a feature defined in the poll documentation (timeout)

yeah the main issue is that the real poll is actually hogging a real OS thread, that means e.g. if you invoke poll_oneoff with a long delay it won't return control to the Go runtime until the underlying poll has returned. This way we avoid relying on the syscall native delay, and we give the Go runtime more chances to take over if necessary (e.g. schedule other goroutines)

so this has more to do with the interaction between Go and the underlying syscall, than how the syscall is actually implemented at the OS-level. I will add some notes to the RATIONALE

the "bonus" is that by using the ctx clock we are also respecting that clock.

This way we avoid relying on the syscall native delay

What I'm probably missing here is that this is a timeout. What I'm thinking and could be wrong, but timeout is the worst case. A delay means it is blocked regardless.

So say 100us and the "file is ready to write" event happens at +10us. Using a clock sleep approach you have to wait extra 90us anyway. If this is correct then it seems we are trying too hard to not use poll's timeout even when Go uses it. In other words, I feel we are trying too hard to not use it, and in the process force a longer delay than necessary (blocking the worst case even when an event occurs before the worst case). What am I missing?

My understanding of the problem/solution is this:

If you poll with timeout:

• the guest unblocks as soon as an event happens;
• but while waiting…
• the host has an OS thread blocked from doing anything else;
• the host can only cancel the guest at timeout intervals.

If you poll zero and sleep the timeout:

• the guest can only unblock at timeout intervals;
• but while sleeping…
• the host OS thread is free to do other things;
• the host can cancel the guest at any time.

Basically this looks like a choice/balance between giving priority to host or guest resources.

For a single guest (like browser) environment, the first one would be the right call, hands down.
For scaling in the backend, I'd be inclined to go with the second, if we can't do better.

since this is introducing a significant change in how we handle poll_oneoff, I will close this PR for now and instead contribute the tests, small cleanups and fixes that were part of it, without modifying how poll_oneoff handles FDs, we can always revisit this :)

#1606 (comment) from @ncruces has basically the concern which was at the crux of this issue.

I would say that the code abandoned and also in the description seems to both say that using blocking via syscall timeout is bad, yet I believe this is actually what go does in net poll.

It makes me wonder how anyone would be able to choose a good value to block the client. Also why anyone would do this if there was only one blocking event. Like the guessed interval would always be wrong even if a little. You are choosing to wait not long enough or too long, unless there's a constant stream of data.

If the project as a whole wants to prevent use of the timeout parameter in the syscall, basically to always block for no time and guess an interval to sleep for (with a syscall each guess).. I feel like the API should change, and remove the ability to give a timeout. (remove the param from File.Poll). Now, it makes even less sense to have a timeout parameter and not use it.

I think personally I've said enough on this and I'll leave any decision up to you all, just maybe decide once and for all in a couple months? because we are exposing the filesystem api and it should make sense why poll would be exposed and never use the timeout val here or in a potential multi-poll scenario.

The thing I believe whatever action to take is, that if we believe wazero should not support integrated syscall pollers, we should be very loud about it. It is a different direction than I expected considering the syscall layer otherwise acts like sys calls. I was expecting a comment like what go has on an emulated thing vs emulating poll behavior and intentionally not allowing native polling, by doing so above where someone has control of the impl (above the fs API)

Basically, I would suggest study the topic in go, like here, make a decision and then try to rationalize both in API and also in the RATIONALE why specifically here only in poll we are doing like this, where other places like blocking Read will still block the calling thread etc. I've an idea that folks can figure out a justification, just I don't want to moderate it.