eio_posix: yield on IO

[talex5]

Before, a read would only yield if it needed to block. This could prevent other fibers from running at all if data was always available and also prevented it from checking for cancellation.

Also, for operations on paths, run the operation in a system thread.

This could be optimised a bit, but this makes it correct at least. I tried it on the wrk benchmark and this change made it faster for some reason!

Part of #456.

[anuragsoni]

I tried it on the wrk benchmark and this change made it faster for some reason!

Just guessing, but if the wrk benchmark was run with a large number of clients maybe the better numbers were because yielding the fiber allowed the runtime to switch to accepting more sockets?

[talex5]

Just guessing, but if the wrk benchmark was run with a large number of clients maybe the better numbers were because yielding the fiber allowed the runtime to switch to accepting more sockets?

Possibly, but in the past I've noticed you can cheat at the benchmark by servicing fewer sockets, as wrk only counts the total responses, without caring if they're distributed fairly! It might also (just guessing here) be that it makes the server switch to another fiber after doing a write, rather than immediately queuing up the next read (which would certainly block).

[anuragsoni]

I've noticed you can cheat at the benchmark by servicing fewer sockets, as wrk only counts the total responses, without caring if they're distributed fairly!

Ah! I did not know this!

it makes the server switch to another fiber after doing a write, rather than immediately queuing up the next read (which would certainly block).

This is quite possible! I've definitely struggled at times to come up with a generic plan for interleaving yields + io when writing shuttle. I was able to punt on the issue a bit because of async not being eager when it comes to binding on a filled promise (I think this in-turn acts as a yield since the event loop will switch control to another task after performing io).

I've yet to spend time with eio but I'm guessing part of the problem here might be the lack of a bind/await etc that would allow automatically switching control to another fiber?

[anuragsoni]

That said, I don't want to de-rail the discussion!! Its been nice to follow the developments here, and this diff should indeed resolve the problem of never accidentally blocking the event loop because of a flow always having more data to read.

[talex5]

I've yet to spend time with eio but I'm guessing part of the problem here might be the lack of a bind/await etc that would allow automatically switching control to another fiber?

Yes. Lwt doesn't yield on bind unless it has to, while I think Async does, so there are two options when you have bind.

I think always switching on IO makes sense (and the eio_linux backend has to do that anyway due to how uring works).

However, in Eio e.g. Promise.await does not yield if the promise is already resolved. I think I prefer to keep it that way because otherwise using resolved promises can be fairly expensive as you switch to another fiber (bad for the cache), and you can always put a yield in manually if you need one.