starkware-libs / blockifier

Blockifier is a Rust implementation for the transaction-executing component in the StarkNet sequencer, in charge of creating state diffs and blocks.
Apache License 2.0
170 stars 108 forks source link

*[`crates/native_blockifier/src/py_block_executor.rs` line 232 at r1](https://reviewable.io/reviews/starkware-libs/blockifier/1978#-O-FDksN1EGp6tu6zRc9:-O-FrNVj512Jw8O4pfDX:bejhvfw) ([raw file](https://github.com/starkware-libs/blockifier/blob/076d771fba9bb281c9906b5ea7b1d44c4dd2bd0e/crates/native_blockifier/src/py_block_executor.rs#L232)):* #1979

Closed noaov1 closed 3 months ago

noaov1 commented 3 months ago
          *[`crates/native_blockifier/src/py_block_executor.rs` line 232 at r1](https://reviewable.io/reviews/starkware-libs/blockifier/1978#-O-FDksN1EGp6tu6zRc9:-O-FrNVj512Jw8O4pfDX:bejhvfw) ([raw file](https://github.com/starkware-libs/blockifier/blob/076d771fba9bb281c9906b5ea7b1d44c4dd2bd0e/crates/native_blockifier/src/py_block_executor.rs#L232)):*
Previously, noaov1 (Noa Oved) wrote…
You are right. I'm not sure why `allow_threads` is needed for running threads in rust. The [docs](https://pyo3.rs/v0.19.1/parallelism) suggest that rayon threads do not need to use `allow_threads`, maybe the std ones do?

The docs say that "pure rust functions" can use threads without worrying about the GIL, but functions that accept Python objects as arguments need to take the GIL before they can spawn a thread.

Originally posted by @avi-starkware in https://github.com/starkware-libs/blockifier/issues/1978#issuecomment-2165082139

I agree. I added the allow_threads code to a function that accepts Python objects but does not spawn any threads. It calls a rust method that spawns threads. BTW- it does not work using rayon threads as well (got timeout).