Reconsider if closing pre-opens are prohibited

[codefromthecrypt]

@loganek recently added a rust close_preopen test , which ensures user code can't close a.. pre-open. In some ways stdio are like pre-opens, as in wazero, we had exactly the opposite request by @vyskocilm which is to ensure stdio can be closed. I'd like to understand how to rationalize both at the same time, even if wazero tentatively blocks closing strict pre-opens (fd=3) while still allowing code to close stdio (implicit pre-opens)

See tetratelabs/wazero#953

[sunfishcode]

Your reasoning makes sense to me. We should change the spec to allow preopens to be closed. I've now filed WebAssembly/WASI#522 to propose this.

[david32768]

Suppose preopens are 3, 4 and 5 and 4 is closed and a new scan of preopens is done then 5 will not be found.

[david32768]

Suppose preopens are 3, 4 and 5 and 4 is closed and a new scan of preopens is done then 5 will not be found.

[codefromthecrypt]

Suppose preopens are 3, 4 and 5 and 4 is closed and a new scan of preopens is done then 5 will not be found.

Interesting, I had noticed that pre-open scans tended to be a one-shot deal (at program init), can you link me something that does this routinely? Something that does could help make a test to ensure they continue to work.

[david32768]

I just want clarity. It is a pity that obtaining predirs is not like args_get and environment_get then the fd's need not be 3,4,...