All input streams are implemented using the HostInputStream trait. Except files. They get special treatment. This can be seen in the definition of InputStream:

The special case was introduced to work around the fact that OS'es don't actually provide any true async APIs for files. A more detailed explanation can be read in the PR that introduced this setup: #6556

Currently, FileInputStream::read spawns the read syscall on a background thread and then immediately awaits the newly created task. This is done to prevent blocking the executor, but from the WASM guest's point-of-view this doesn't provide any asynchronicity.

My question: Instead of directly awaiting the background task, can we store the task handle in the FileInputStream instance and then use that handle to wait for readiness? Subsequent calls to FileInputStream::read then inspect the result of the previously started background task (if any). And then let FileInputStream implement HostInputStream directly and get rid of the special case.

From the surface this seems like an "obvious" solution, but the PR above also mentions:

We spent a the better part of a week trying to square this circle and this is the best we could come up to make files work

which makes me suspect there's more to the story than meets the eye.

@pchickey, what do you think?