github-actions[bot] commented on Issue #1561:
Subscribe to Label Action
cc @kubkon
<details>
This issue or pull request has been labeled: "wasi"Thus the following users have been cc'd because of the following labels:
- kubkon: wasi
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
kubkon commented on Issue #1561:
Hmm, so I reckon this PR is at a stage that's ready for review so I'll mark it as such. Besides the major changes to the way we treat OS handles, there's a couple more things I'm somewhat unclear on:
- Should OS-specific
path
,fd
accept specific types such asOsFile
,OsDir
, andstd::fs::File
for syscalls that are OS handle-independent (e.g.,fdstat_get
)? This approach is currently presented in this PR, and it makes our intention a bit clearer what handle is expected for this OS-specific syscall to be called on. But then again, should we ever expand on different handle types and make some syscalls that are currently _only_ used byOsFile
say, it would be more ergnonomic for the syscalls to simply acceptstd::fs::File
.- On the topic of using
std::fs::File
, the reason we currently have our _own_ type that resembles that ofstd::fs::File
(OsHandle
andOsDirHandle
) is because this way we can wrap the underlying OS handle (RawFd
orRawHandle
) in astd::cell::Cell
. Interior mutability _is_ required infd_fdstat_set_flags
call on Windows, where adjusting the flags can only be done by reopening the said file (am I correct here @peterhuene?). We could in principle wrapstd::fs::File
in astd::cell::RefCell
but then we are risking a panic somewhere down the line. Perhaps though this risk is worth accepting at the benefit of cleaner codebase?Anyhow, all thoughts, suggestions are more than welcome!
kubkon commented on Issue #1561:
@alexcrichton even though you might not know all the internals very well, I'd appreciate your opinion on this even if high level!
Last updated: Nov 22 2024 at 17:03 UTC