Stream: git-wasmtime

Topic: wasmtime / Issue #1308 [wiggle] Obtaining another WASI ha...

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:41):

kubkon opened Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:41):

kubkon assigned Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:41):

kubkon assigned Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:41):

kubkon labeled Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:41):

kubkon labeled Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:41):

kubkon labeled Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Wasmtime GitHub notifications bot (Mar 13 2020 at 16:00):

sunfishcode commented on Issue #1308:

In an application which opens and closes many handles, we'll want to be able to reuse handle values. To support this, we'll need to move away from "add one to a handle" and toward "ask the context for a free handle", and have the context reuse closed handles.

Wasmtime GitHub notifications bot (Mar 13 2020 at 16:21):

alexcrichton commented on Issue #1308:

I'd imagine the same as @sunfishcode where it seems like the underlying code should best be changed to something that doesn't require this sort of addition. It sounds like an FdSet which has something like an allocate and deallocate method which tracks all the indices is probably what's best here?

Wasmtime GitHub notifications bot (Mar 13 2020 at 19:16):

kubkon commented on Issue #1308:

I’m glad I run it past both of you! It makes perfect sense for the context to provide next available handle.

Since this is essentially required to swap wig for wiggle, I’m gonna provide a draft PR of how I’d see this work and we can carry on our discussion there. Does that make sense to y’all?

Wasmtime GitHub notifications bot (Mar 13 2020 at 19:23):

sunfishcode commented on Issue #1308:

Makes sense!

Wasmtime GitHub notifications bot (Mar 17 2020 at 22:47):

kubkon commented on Issue #1308:

I’m gonna go ahead and close this one since we’ve solved the issue in #1329.

Wasmtime GitHub notifications bot (Mar 17 2020 at 22:47):

kubkon closed Issue #1308 (assigned to pchickey):

As in the title, pre-wiggle, we didn't really deal with a concept of WASI handle, and file descriptor was simply a type alias. Now, with wiggle, we can and should handle "handles" properly.

My question now is, how should we obtain a handle from another one in wasi-common? Until now (when Fd was a simple type alias) we did:

let new_fd = if let Some(fd) = old_fd.checked_add(1) {
    fd
} else {
   Overflow
}

Since Fd is now a "supertype", it's no longer that obvious what to do. My initial thought was to provide an unsafe accessor to the underlying value in wiggle, i.e., something like:

pub struct Fd(u32);
impl Fd {
    pub unsafe fn inner(&self) -> u32 {
        self.0
   }
}

Then, we could re-use most of the code in wasi-common to obtain a new handle as follows:

let new_fd = if let Some(raw) = unsafe { old_fd.inner() }.checked_add(1) {
    Fd::from(raw)
} else {
    Overflow
}

I'm wondering though if you guys reckon there is a better, cleaner way of dealing with this? Perhaps a method on the handle type, next() -> Self say, that will return another valid handle. But then, I guess it won't necessarily possess a notion of valid means without having access to the current WASI context object, right?

cc @alexcrichton I thought might be of interest for you as well.

Last updated: Nov 22 2024 at 17:03 UTC