if you’re really that bothered…
use std::sync::{Mutex, MutexGuard};
trait ULock<'a> {
type Guard;
fn ulock(&'a self) -> Self::Guard;
}
impl<'a, T: 'a> ULock<'a> for Mutex<T> {
type Guard = MutexGuard<'a, T>;
fn ulock(&'a self) -> Self::Guard {
self.lock().unwrap()
}
}
or use a wrapper struct, if you really really want the method to be called exactly lock.
If lock-ergonomicsⓒ is as relevant to you as indexing, you’re doing it wrong.
I would rather take indexing returning Results than the other way around.
One can always wrap any code in {||{ //.. }}() and use question marks liberally anyway (I call them stable try blocks 😉).
…and that’s how you drive up metrics.
Gross!
Unprofessional.
This is why no one takes Rust seriously.
but futures only execute when polled.
The most interesting part here is the polling only has to take place on the scope itself. That was actually what I wanted to check, but got distracted because all spawns are awaited in the scope in moro’s README example.
async fn slp() {
tokio::time::sleep(std::time::Duration::from_millis(1)).await
}
async fn _main() {
let result_fut = moro::async_scope!(|scope| {
dbg!("d1");
scope.spawn(async {
dbg!("f1a");
slp().await;
slp().await;
slp().await;
dbg!("f1b");
});
dbg!("d2"); // 11
scope.spawn(async {
dbg!("f2a");
slp().await;
slp().await;
dbg!("f2b");
});
dbg!("d3"); // 14
scope.spawn(async {
dbg!("f3a");
slp().await;
dbg!("f3b");
});
dbg!("d4");
async { dbg!("b1"); } // never executes
});
slp().await;
dbg!("o1");
let _ = result_fut.await;
}
fn main() {
let rt = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(_main())
}
[src/main.rs:32:5] "o1" = "o1"
[src/main.rs:7:9] "d1" = "d1"
[src/main.rs:15:9] "d2" = "d2"
[src/main.rs:22:9] "d3" = "d3"
[src/main.rs:28:9] "d4" = "d4"
[src/main.rs:9:13] "f1a" = "f1a"
[src/main.rs:17:13] "f2a" = "f2a"
[src/main.rs:24:13] "f3a" = "f3a"
[src/main.rs:26:13] "f3b" = "f3b"
[src/main.rs:20:13] "f2b" = "f2b"
[src/main.rs:13:13] "f1b" = "f1b"
The non-awaited jobs are run concurrently as the moro docs say. But what if we immediately await f2?
[src/main.rs:32:5] "o1" = "o1"
[src/main.rs:7:9] "d1" = "d1"
[src/main.rs:15:9] "d2" = "d2"
[src/main.rs:9:13] "f1a" = "f1a"
[src/main.rs:17:13] "f2a" = "f2a"
[src/main.rs:20:13] "f2b" = "f2b"
[src/main.rs:22:9] "d3" = "d3"
[src/main.rs:28:9] "d4" = "d4"
[src/main.rs:24:13] "f3a" = "f3a"
[src/main.rs:13:13] "f1b" = "f1b"
[src/main.rs:26:13] "f3b" = "f3b"
f1 and f2 are run concurrently, f3 is run after f2 finishes, but doesn’t have to wait for f1 to finish, which is maybe obvious, but… (see below).
So two things here:
defer_to_scope() be confusing if the job is awaited in the scope?I skimmed the latter parts of this post since I felt like I read it all before, but I think moro is new to me. I was intrigued to find out how scoped span exactly behaves.
async fn slp() {
tokio::time::sleep(std::time::Duration::from_millis(1)).await
}
async fn _main() {
let value = 22;
let result_fut = moro::async_scope!(|scope| {
dbg!(); // line 8
let future1 = scope.spawn(async {
slp().await;
dbg!(); // line 11
let future2 = scope.spawn(async {
slp().await;
dbg!(); // line 14
value // access stack values that outlive scope
});
slp().await;
dbg!(); // line 18
let v = future2.await * 2;
v
});
slp().await;
dbg!(); // line 25
let v = future1.await * 2;
slp().await;
dbg!(); // line 28
v
});
slp().await;
dbg!(); // line 32
let result = result_fut.await;
eprintln!("{result}"); // prints 88
}
fn main() {
// same output with `new_current_thread()` of course
let rt = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(_main())
}
This prints:
[src/main.rs:32:5]
[src/main.rs:8:9]
[src/main.rs:25:9]
[src/main.rs:11:13]
[src/main.rs:18:13]
[src/main.rs:14:17]
[src/main.rs:28:9]
88
So scoped spawn doesn’t really spawn tasks as one might mistakenly think!
The LARPing levels in moronix comments are higher than usual, but the comedic value is still not lost.
I think your second link isn’t what you intended?
You scared me for a moment there. I don’t know why you thought that.
Needless to say, even with the first example, metavar expressions are not strictly needed here, as using a second pattern and recursing expansions would work.
But I wanted to showcase the power of ${ignore}, as it can be cleaner and/or more powerful in some cases where extra patterns and recursing expansions can get messy and hard to track.
Is this crazy?
A general repeat macro that works on stable Rust would work too of course.
First of all, unsafe famously doesn’t disable the borrow checker, which is something any Rustacean would know, so your intro is a bit weird in that regard.
And if you neither like the borrow checker, nor like unsafe rust as is, then why are you forcing yourself to use Rust at all. If you’re bored with C++, there are other of languages out there, a couple of which are even primarily developed by game developers, for game developers.
The fact that you found a pattern that can be alternatively titled “A Generic Method For Introducing Heisenbugs In Rust”, and you are somehow excited about it, indicates that you probably should stop this endeavor.
Generally speaking, I think the Rust community would benefit from making an announcement a long the lines of “If you’re a game developer, then we strongly advise you to become a Rustacean outside the field of game development first, before considering doing game development in Rust”.
for a build of your crate only: single core perf.
Until the parallel compiler feature (-Z threads=<n>) stabilizes and becomes more complete.
It’s also always worth mentioning that the choice of linker is important. Using mold or lld can significantly speed things up in some use-cases.
Beyond that, codegen-units and lto profile options are also important.
And finally, for development purposes, the code generator is important, as cranelift provides much faster compile times, but resulting binaries are not as optimized as LLVM-generated ones.
Hate to break it to you, but you’re not really learning.
I thought I saw this weeks ago.
May 21, 2024
yep
Anyway, neovim+rust-analyzer+ra-multiplex is all I need.
The hacker news comments are as usual very good too
lol
p.s. I’m also curious if you have any actual evidence that these two are more reliable than gtk. It’s reasonable to think they might be, but I’d like something more than “they’re written in Rust and have fewer features.”
I based my suggestion based on the logical requirement stated (first quote) which was later ignored (second quote).
I didn’t make any specific claims about imaginary reliability score points.
The crash reporter has a very unique requirement: it must use as little as possible of the Firefox code base, ideally none!
we already ship GTK with Firefox on Linux to make a modern-feeling GUI, so we can use it for the crash reporter, too.
I’m almost hoping for some GTK-caused crashes. They can enjoy the native look and feel while debugging that!
Maybe then they will learn how to stick fully to logical requirements instead of going for “meh big dependency” and “meh look and feel”.
What’s interesting is that this problem is largely solved for C and C++: Linux distributions like Debian
[closes tab]
That’s exactly what’s done above using an extension trait! You can
mutex_val.ulock()with it!That’s why you’re told (clippy does that i think) to use
expectinstead, so you can signal “whatever string” you want to signal precisely.