A Rusty blog about Rusty things
Using multiple tasks is probably the most common way to perform non-sequential work in Rust. Each task can wait for a different IO event, and the async runtime will schedule the tasks to do work as soon as the IO events occur. This provides for a simple and convenient way to "non-blockingly" wait for these IO events to happen and achieve concurrency. But sharing mutable state among the tasks can…
So, let's say you have a clean and nice function like this. use std::pin::Pin; async fn foo () -> u32 { let mut x = 1 ; tokio::time::sleep(std::time::Duration::from_secs( 0 )).await; x += 1 ; x } #[ tokio :: main ] async fn main () { let mut x = foo (); let a = unsafe { Pin::new_unchecked( & mut x) }; println!( " {} " , a.await); } Everything looks nice except for that Pin::new_unchecked which we…
The way method resolution works in Rust is specified in this section of the reference. For a given type T where a method is being called, it follows these steps: Start with a candidate list containing only T ( candidates := [T] ) Try to dereference ( * ) the last element of the list( last ) If *last is valid, add it to the list ( candidates := candidates : [last] ) and go to the previous step.…
The way method resolution works in Rust is specified in this section of the reference.
'twas a lovely Sunday afternoon when I decided to do some fun rust quiz , but a subtle mistake in the explanation of the answer ended up in hours of research and a PR.
I was experimenting with the lifetime constraints for tokio channels, I wanted to understand how it enforces sane lifetimes for the type of the value sended.