Threading improvements

[n13]

Remove blocking executor and unnecessary mutex from mining submission

The mining loop (qpow-mining) runs as an async task on the tokio thread pool. Block submission previously used futures::executor::block_on(worker_handle.submit(seal)), which parked the tokio worker thread for the duration of the block import. This was a workaround because parking_lot::MutexGuard is !Send, making the submit() future incompatible with .await in a tokio context.

The underlying issue was that block_import was wrapped in a parking_lot::Mutex despite not needing one -- BlockImport::import_block takes &self, and submit() is only ever called from the single mining loop. There is no concurrent access to synchronize.

Changes:

• Remove the Mutex around block_import in MiningHandle, replacing Arc<Mutex<BoxBlockImport>> with Arc<BoxBlockImport>
• Replace futures::executor::block_on(worker_handle.submit(seal)) with .await at both call sites
• Make submit_mined_block async
• Remove #[allow(clippy::await_holding_lock)]

[n13]

Gemini loves it

This is an excellent PR! 🎉 I've checked out the code and reviewed the changes. Everything compiles perfectly and the logic is very sound.

Here is my review of the changes:

🌟 The Good Stuff

• No More Thread Starvation: Removing futures::executor::block_on from the async tokio context is a huge win! Blocking calls inside a tokio worker thread can easily lead to thread pool starvation or even deadlocks, so replacing it with .await is definitely the right move.
• Simplified Concurrency: Removing the parking_lot::Mutex around block_import in MiningHandle is a great cleanup. As the PR description rightly points out, submit() is only executed sequentially from within the mining_loop task, so concurrent mutable access synchronization was completely unnecessary.
• Clean Async Propagation: Making submit_mined_block an async fn and properly propagating the .await up through handle_external_mining and the mining_loop keeps the async control flow very clean and idiomatic.
• Cleaner Linting: Removing the #[allow(clippy::await_holding_lock)] attribute is always satisfying and proves the architecture is now naturally safe without requiring compiler exception workarounds.

💡 Conclusion

The code is completely solid, minimal, and fully adheres to Rust's concurrency guarantees (the compiler perfectly proves that the Mutex wasn't needed for trait satisfaction). This will definitely improve the responsiveness and performance of the mining loop!

[n13]

GPT and Grok also love it

[illuzen]

I think the fact that only one thread needs it also means that blocking would not make much of a difference, but I like the simplicity