kubkon edited PR #1395 from mut-cleanup
to master
:
Until now, several syscalls including
fd_pwrite
etc. were relying on mutating&mut Entry
by mutating its inner file handle. This is unnecessary in almost all cases since all methods mutatingstd::fs::File
in Rust's libstd are also implemented for&std::fs::File
. In part, this will prepare us to handleEntry
s behind anRc
andRefCell
combo.While here, I've also modified
OsHandle
in BSD to includeRefCell<Option<Dir>>
rather thanOption<Mutex<Dir>>
as was until now. WhileRefCell
could easily be replaced withMutex
, since going multithreading will require a lot of conceptual changes towasi-common
, I thought it'd be best not to mix single- with multithreading contexts and swap all places at once when it comes to it. If y'all feel this is not the right approach, lemme know!I've also had to make some modifications to virtual FS which mainly swaps mutability for interior mutability in a handful of places.
sunfishcode submitted PR Review.
sunfishcode submitted PR Review.
sunfishcode created PR Review Comment:
What is the
mut
here for?
alexcrichton submitted PR Review.
alexcrichton created PR Review Comment:
The way this technically works is it's dispatching to the
impl Seek for &File
where the seek method takes&mut self
. This means that we're calling seek on&mut &File
, so themut
here is needed to create the&mut &File
binding.
kubkon submitted PR Review.
kubkon created PR Review Comment:
This is to be able to mutate the reference to reference to
File
. Another way of expressing it would be(&mut (&*fd as &File)).read_vectored(...)This looks too cluttered for me, hence why I’ve decided to
let
-bind it first. However, if you know of a better way of handling this, lemme know!
alexcrichton submitted PR Review.
alexcrichton created PR Review Comment:
For one-liners like this it should suffice to do
(&fd).seek(pos)
kubkon created PR Review Comment:
@alexcrichton again beat me to it! Seconds, seconds!
kubkon submitted PR Review.
alexcrichton submitted PR Review.
kubkon submitted PR Review.
kubkon created PR Review Comment:
I tried but alas wouldn’t work. The compiler complained that cannot mutate
File
behind a&
ref. I think this might be sincefd
is not aFile
but rather an entity that implementsDeref<Target=File>
so would need something like(&mut (&*fd as &File))
. Unless I’m doing something wrong here.
kubkon updated PR #1395 from mut-cleanup
to master
:
Until now, several syscalls including
fd_pwrite
etc. were relying on mutating&mut Entry
by mutating its inner file handle. This is unnecessary in almost all cases since all methods mutatingstd::fs::File
in Rust's libstd are also implemented for&std::fs::File
. In part, this will prepare us to handleEntry
s behind anRc
andRefCell
combo.While here, I've also modified
OsHandle
in BSD to includeRefCell<Option<Dir>>
rather thanOption<Mutex<Dir>>
as was until now. WhileRefCell
could easily be replaced withMutex
, since going multithreading will require a lot of conceptual changes towasi-common
, I thought it'd be best not to mix single- with multithreading contexts and swap all places at once when it comes to it. If y'all feel this is not the right approach, lemme know!I've also had to make some modifications to virtual FS which mainly swaps mutability for interior mutability in a handful of places.
kubkon created PR Review Comment:
Ok, I've convinced myself that this is due to the fact that
fd
is anOsHandle
and not aFile
nor&File
. Hence, we need to force it to coerce to&File
before calling the trait method such asseek
on it. The minimum working one-liner I got down to is(fd as &File).seek(pos)?
. I'm happy to leave several as one-liners such as this one, unless we re-use thefd
in a couple of places within the same scope, in which caselet mut fd: &File = fd;
seems more natural.
kubkon submitted PR Review.
kubkon merged PR #1395.
Last updated: Nov 22 2024 at 17:03 UTC