This question is written for Yew v0.19
Asynchronous foreign JavaScript functions can be used in Rust through Closures, as the function to pass-in:
#[wasm_bindgen]
extern "C" {
fn setInterval(closure: &Closure<dyn FnMut()>, time: u32) -> i32;
}
// ...
let cb = Closure::new(|| {
log("interval elapsed!");
});
let interval_id = setInterval(&cb, 1_000);
This is nice for a pedantic examples, but Closures have a critical requirement - the function applied needs to have a 'static lifetime. Likewise, with Yew applications, a perfect mechanism for spontaneous response is the Message enum, and having it update() the Model. However, the link() mechanism in Context (which issues messages) does not have a static lifetime.
In an ideal world, the value submitted to the closure could just be applied as a Yew component message:
struct Model {
thing: Option<JsValue>,
}
enum Msg {
GotThing(JsValue),
}
#[wasm_bindgen]
extern "C" {
fn createThing(closure: &Closure<dyn FnMut(JsValue) -> ());
}
impl Component for Model {
type Message = Msg;
type Properties = ();
fn create(_ctx: &Context<Self>) -> Self {
Model {
thing: None, // initial value
}
}
fn update(&mut self, _ctx: &Context<Self>, msg: Self::Message) -> bool {
match msg {
Msg::GotThing(x) => { // handle the message
self.thing = Some(x);
true
},
}
}
fn rendered(&mut self, ctx: &Context<Self>, first_render: bool) {
if first_render {
let cb: Box<dyn FnMut(JsValue) -> ()> = Box::new(|x| {
// try and issue the message
ctx.link().send_message(Msg::GotThing(x));
// ^ doesn't have a `'static` lifetime! Won't compile
});
createThing(Closure::wrap(&cb));
}
}
// fn view() ... omitted, not relevant
}
I'm wondering if there's a way to convert a Callback into a Closure, or if there's a better, more canonical way to do this, to please correct me.
Another idea I had would use some kind of queue defined statically (which wouldn't be safe as it's a mutable static variable), but then it could be used as an intermediary data type between the Closure passed to createThing, and messages could be dispatched within the component.
Maybe there's an external way to interact with a Yew component that I'm overlooking? I'm not sure how to resolve this issue. What would be the most correct way to achieve this goal?
Related
I'm trying to implement a stream in Rust for use in a tonic GRPC handler and encountered this difficulty: most ways of creating streams don't have easily-expressible types, yet the GRPC trait I need to implement requires a specific Stream type. Something like this (simplified):
// trait to implement
trait GrpcHandler {
type RespStream: futures::Stream<ResponseType> + Send + 'static
fn get_resp_stream() -> Self::RespStream;
}
// a start at implementing it
impl GrpcHandler for MyHandler {
type RespStream = ???; // what do I put here?
fn get_resp_stream() -> Self::RespStream {
futures::stream::unfold((), |_| async {
tokio::time::sleep(tokio::time::Duration::from_secs(1)).await;
Some((ResponseType {}, ()))
})
}
}
I know the type of my stream is technically something like Unfold<(), ComplicatedFnSignatureWithImpl, ComplicatedFutureSignatureWithImpl>, but even if I typed that whole thing in, the compiler wouldn't be happy about it being an opaque type.
How can I refer to the type of this stream?
Unfortunately there is no good way in stable Rust to do that without dynamic dispatch. You have to use dyn Stream, and futures provides BoxStream for that:
impl GrpcHandler for MyHandler {
type RespStream = futures::stream::BoxStream<'static, ResponseType>;
fn get_resp_stream() -> Self::RespStream {
futures::stream::unfold((), |_| async {
tokio::time::sleep(tokio::time::Duration::from_secs(1)).await;
Some((ResponseType {}, ()))
})
.boxed()
}
}
If you use nightly, you can use the unstable type_alias_impl_trait feature to avoid the overhead of dynamic dispatch:
#![feature(type_alias_impl_trait)]
impl GrpcHandler for MyHandler {
type RespStream = impl futures::Stream<Item = ResponseType> + Send + 'static;
fn get_resp_stream() -> Self::RespStream {
futures::stream::unfold((), |_| async {
tokio::time::sleep(tokio::time::Duration::from_secs(1)).await;
Some((ResponseType {}, ()))
})
}
}
I have an object that I know that is inside an Arc because all the instances are always Arced. I would like to be able to pass a cloned Arc of myself in a function call. The thing I am calling will call me back later on other threads.
In C++, there is a standard mixin called enable_shared_from_this. It enables me to do exactly this
class Bus : public std::enable_shared_from_this<Bus>
{
....
void SetupDevice(Device device,...)
{
device->Attach(shared_from_this());
}
}
If this object is not under shared_ptr management (the closest C++ has to Arc) then this will fail at run time.
I cannot find an equivalent.
EDIT:
Here is an example of why its needed. I have a timerqueue library. It allows a client to request an arbitrary closure to be run at some point in the future. The code is run on a dedicated thread. To use it you must pass a closure of the function you want to be executed later.
use std::time::{Duration, Instant};
use timerqueue::*;
use parking_lot::Mutex;
use std::sync::{Arc,Weak};
use std::ops::{DerefMut};
// inline me keeper cos not on github
pub struct MeKeeper<T> {
them: Mutex<Weak<T>>,
}
impl<T> MeKeeper<T> {
pub fn new() -> Self {
Self {
them: Mutex::new(Weak::new()),
}
}
pub fn save(&self, arc: &Arc<T>) {
*self.them.lock().deref_mut() = Arc::downgrade(arc);
}
pub fn get(&self) -> Arc<T> {
match self.them.lock().upgrade() {
Some(arc) => return arc,
None => unreachable!(),
}
}
}
// -----------------------------------
struct Test {
data:String,
me: MeKeeper<Self>,
}
impl Test {
pub fn new() -> Arc<Test>{
let arc = Arc::new(Self {
me: MeKeeper::new(),
data: "Yo".to_string()
});
arc.me.save(&arc);
arc
}
fn task(&self) {
println!("{}", self.data);
}
// in real use case the TQ and a ton of other status data is passed in the new call for Test
// to keep things simple here the 'container' passes tq as an arg
pub fn do_stuff(&self, tq: &TimerQueue) {
// stuff includes a async task that must be done in 1 second
//.....
let me = self.me.get().clone();
tq.queue(
Box::new(move || me.task()),
"x".to_string(),
Instant::now() + Duration::from_millis(1000),
);
}
}
fn main() {
// in real case (PDP11 emulator) there is a Bus class owning tons of objects thats
// alive for the whole duration
let tq = Arc::new(TimerQueue::new());
let test = Test::new();
test.do_stuff(&*tq);
// just to keep everything alive while we wait
let mut input = String::new();
std::io::stdin().read_line(&mut input).unwrap();
}
cargo toml
[package]
name = "tqclient"
version = "0.1.0"
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
timerqueue = { git = "https://github.com/pm100/timerqueue.git" }
parking_lot = "0.11"
There is no way to go from a &self to the Arc that self is stored in. This is because:
Rust references have additional assumptions compared to C++ references that would make such a conversion undefined behavior.
Rust's implementation of Arc does not even expose the information necessary to determine whether self is stored in an Arc or not.
Luckily, there is an alternative approach. Instead of creating a &self to the value inside the Arc, and passing that to the method, pass the Arc directly to the method that needs to access it. You can do that like this:
use std::sync::Arc;
struct Shared {
field: String,
}
impl Shared {
fn print_field(self: Arc<Self>) {
let clone: Arc<Shared> = self.clone();
println!("{}", clone.field);
}
}
Then the print_field function can only be called on an Shared encapsulated in an Arc.
having found that I needed this three times in recent days I decided to stop trying to come up with other designs. Maybe poor data design as far as rust is concerned but I needed it.
Works by changing the new function of the types using it to return an Arc rather than a raw self. All my objects are arced anyway, before they were arced by the caller, now its forced.
mini util library called mekeeper
use parking_lot::Mutex;
use std::sync::{Arc,Weak};
use std::ops::{DerefMut};
pub struct MeKeeper<T> {
them: Mutex<Weak<T>>,
}
impl<T> MeKeeper<T> {
pub fn new() -> Self {
Self {
them: Mutex::new(Weak::new()),
}
}
pub fn save(&self, arc: &Arc<T>) {
*self.them.lock().deref_mut() = Arc::downgrade(arc);
}
pub fn get(&self) -> Arc<T> {
match self.them.lock().upgrade() {
Some(arc) => return arc,
None => unreachable!(),
}
}
}
to use it
pub struct Test {
me: MeKeeper<Self>,
foo:i8,
}
impl Test {
pub fn new() -> Arc<Self> {
let arc = Arc::new(Test {
me: MeKeeper::new(),
foo:42
});
arc.me.save(&arc);
arc
}
}
now when an instance of Test wants to call a function that requires it to pass in an Arc it does:
fn nargle(){
let me = me.get();
Ooddle::fertang(me,42);// fertang needs an Arc<T>
}
the weak use is what the shared_from_this does so as to prevent refcount deadlocks, I stole that idea.
The unreachable path is safe because the only place that can call MeKeeper::get is the instance of T (Test here) that owns it and that call can only happen if the T instance is alive. Hence no none return from weak::upgrade
I'm working with a library that uses Rust types to keep track of state. As a simplified example, say you have two structs:
struct FirstStruct {}
struct SecondStruct {}
impl FirstStruct {
pub fn new() -> FirstStruct {
FirstStruct {}
}
pub fn second(self) -> SecondStruct {
SecondStruct {}
}
// configuration methods defined in this struct
}
impl SecondStruct {
pub fn print_something(&self) {
println!("something");
}
pub fn first(self) -> FirstStruct {
FirstStruct {}
}
}
And to actually use these structs you usually follow a pattern like so, after printing you may stay in second state or go back to first state depending on how you're using the library:
fn main() {
let first = FirstStruct::new();
let second = first.second(); // consumes first
second.print_something();
// go back to default state
let _first = second.first();
}
I want to create my own struct that handles the state changes internally and simplifies the interface. This also lets me have a single mutable reference around that I can pass to other functions and call the print method. Using it should look something like this:
fn main() {
let mut combined = CombinedStruct::new(FirstStruct::new());
combined.print();
}
I've come up with the following solution that works, at least in this simplified example:
enum StructState {
First(FirstStruct),
Second(SecondStruct),
}
struct CombinedStruct {
state: Option<StructState>,
}
impl CombinedStruct {
pub fn new(first: FirstStruct) -> CombinedStruct {
CombinedStruct {
state: Some(StructState::First(first)),
}
}
pub fn print(&mut self) {
let s = match self.state.take() {
Some(s) => match s {
StructState::First(first) => first.second(),
StructState::Second(second) => second,
},
None => panic!(),
};
s.print_something();
// If I forget to do this, then I lose access to my struct
// and next call will panic
self.state = Some(StructState::First(s.first()));
}
}
I'm still pretty new to Rust but this doesn't look right to me. I'm not sure if there's a concept I'm missing that could simplify this or if this solution could lead to ownership problems as my application gets more complicated. Is there a better way to do this?
Playground link
I once had a similar problem and went basically with your solution, but I avoided the Option.
I.e. I basically kept your
enum StructState {
First(FirstStruct),
Second(SecondStruct),
}
If an operation tries to convert a FirstStruct to a SecondStruct, I introduced a function try_to_second roughly as follows:
impl StructState {
fn try_to_second(self) -> Result<SecondState, StructState> {
/// implementation
}
}
In this case, an Err indicates that the StructState has not been converted to SecondStruct and preserves the status quo, while an Ok value indicates successfull conversion.
As an alternative, you could try to define try_to_second on FirstStruct:
impl FirstStruct {
fn try_to_second(self) -> Result<FirstStruct, SecondStruct> {
/// implementation
}
}
Again, Err/Ok denote failure/success, but in this case, you have more concrete information encoded in the type.
In the code below, removing the second line will result in a compilation error saying:
type `std::io::net::tcp::TcpListener` does not implement any method in scope named `listen`
Since I am nowhere directly using Listener (even though std uses it internally), why do I need to specify it?
use std::io::{TcpListener, TcpStream};
use std::io::{Acceptor, Listener};
fn handle_client(mut stream: TcpStream) {
// ...
}
fn main() {
let args = std::os::args();
println!("{}", args);
let listener = TcpListener::bind("127.0.0.1", 80).unwrap();
let mut acceptor = listener.listen().unwrap();
for stream in acceptor.incoming() {
spawn(proc() {
handle_client(stream.unwrap());
});
}
}
It was a design decision of the language to require explicit use of traits that implement methods. For example in the following code:
use my::A;
use my::B;
mod my {
pub trait A {
fn foo(&self);
}
pub struct B;
impl B {
pub fn bar(&self) {
println!("Called `bar`.");
}
}
impl A for B {
fn foo(&self) {
println!("Called `foo`.");
}
}
}
fn main() {
// Requires "use my::B".
let b = B;
b.bar();
// Requires "use my::A".
b.foo();
}
I believe the motivation for this is heavily due to the fact that currently there is no seamless way to support multiple traits with the same method name. There is a lot of work being done to traits atm however https://github.com/rust-lang/rfcs/blob/master/active/0024-traits.md.
Listener is a trait, and your code uses its listen method, implemented by TcpListener
http://static.rust-lang.org/doc/master/std/io/trait.Listener.html
struct Floor{
requestHandler: Option<RequestHandler>
}
struct RequestHandler{
uri: StrBuf,
handler: fn() -> StrBuf
}
impl Floor {
fn do_something(&self){
//(&self.requestHandler.unwrap().handler)();
//expected function but found `&fn() -> std::strbuf::StrBuf`
//(*(&self.requestHandler.unwrap().handler))();
//cannot move out of dereference of `&`-pointer
//(self.requestHandler.unwrap().handler)();
//cannot move out of dereference of `&`-pointer
}
}
fn main() {
let foo = Floor {
requestHandler: None
};
foo.do_something();
}
In do_something I try to get to my fn which is stored on the handler property of my RequestHandler struct.
Whatever I try, I just seem to be unable to call it (see the compiler messages beneath my failed attempts in the code).
The problem is the signature of Option.unwrap:
impl Option<T> {
fn unwrap(self) -> T { ... }
}
That is, it is taking the Option by value. RequestHandler has to move when used by value, since StrBuf moves (specifically StrBuf isn't Copy which forces RequestHandler to also not be Copy).
The correct way to handle this is to call Option.as_ref:
impl Option<T> {
fn unwrap<'r>(&'r self) -> Option<&'r T> { ... }
}
That is, it takes a reference to an Option and gives you an Option containing a reference to what the original Option contained, this means that .unwrap will then give you that reference, pointing to the RequestHandler inside self, to handle as you wish.
(self.requesthandler.as_ref().unwrap().handler)()