This was a great suggestion! Although, I changed the intermediate structure (to keep the original ordering of rows) in a way that the HashMap is no longer necessary, I can see that even in the new intermediate structure, for small keys, ahash is faster than std hash algorithm (and much faster than BTreeMap) // Previous pub enum Node { Leaf(Value), Internal(BTreeMap<Vec<Value>, HashMap<String, Node>>), Root(HashMap<String, Node>), } //New pub struct MapList { pub rows: Vec<Vec<Node>>, pub rows_lookup: AHashMap<Vec<Value>, usize ..read more

I'm new to Rust. I want to implement a node addon with napi-rs for sending and receiving msg by TCP; here is my code // store TcpStream lazy_static::lazy_static! { static ref TCP_STREAM: Arc<Mutex<Option<TcpStream>>> = Arc::new(Mutex::new(None)); } #[napi] pub async fn send_msg() -> Result<()> { let mut tcp = TCP_STREAM.lock().unwrap(); let tcp_stream = tcp .as_mut() .ok_or_else(|| Error::new(Status::GenericFailure, "Not connected".to_string()))?; // here send msg to server tcp_stream.write("hello Rust".as_bytes()).await?; Ok(()) } #[napi] pub a ..read more

I overlooked the spawn_handler function. Constructing the rayon threadpool explicitly is indeed better in my scenario. This solved my problem ..read more

If you're creating a rayon thread pool explicitly, you can use ThreadPoolBuilder::spawn_handler() to provide a thread-spawning function that does the enter() without forgetting anything ..read more

mainly just backsolving my hand implementation into macro form. Trying to be general within my crate and error when a field isn't being displayed, but not a totally general any widget any gui type macro ..read more

Thanks, I will use this solution, I can use some macro to reduce code for different levels ..read more

As you pointed out, that's a memory leak. It may be untenable for a long-lived process, especially if it happens often or has the potential to happen often because the leak occurs in a public API. There are no correctness issues with leaking the guard, however. Avoiding the need to pass a Handle is a matter of using static or scoped references that the thread pool has access to. Static if the tokio runtime is shared application-wide, or scoped if different thread pools need to use their own runtimes. Something like that should work [1]. Tokio itself uses thread-locals for setting the current ..read more

I encountered the following scenario: Some logic needs to fire tokio::spawn and related runtime functionalities, and then basically forget it. These logic often executes in a rayon threadpool Explicitly passing tokio::runtime::Handle around will damage other interface designs Therefore, it is better to pave all rayon threads during their initialization with tokio contexts. In order to pave rayon threads, I can only think of calling tokio::runtime::Runtime::enter and then std::mem::forget the tokio::runtime::EnterGuard. Basically, rayon_threadpool.broadcast(|_| { let _guard = tok ..read more

The 'static bound on the event loop closure was removed in winit 0.29, so it should not fail with that error. I'm also not able to reproduce your compile failure at all. The build works fine for me on both Windows and Linux, regardless of whether cpal is included in the dependency tree. I'm on a nightly compiler on both platforms, if it matters (doubtful). The Linux nightly is old: rustc 1.78.0-nightly (b6d2d841b 2024-03-05) The most likely explanation so far is that you are somehow using an older version of winit ..read more

Thanks ..read more