Open horizondeep opened 9 months ago
Hi @ritchie46. Can you please have a look into it.
Any update on this @ritchie46 / @stinodego ....?
@horizondeep Could you post an error with the full backtrace from RUST_BACKTRACE=1
?
Hi @orlp. Apologies for the delayed response. Below is the backtrace:
[2024-01-24T18:50:32.512Z] thread 'block_on
) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
[2024-01-24T18:50:32.512Z] stack backtrace:
[2024-01-24T18:50:32.554Z] 0: rust_begin_unwind
[2024-01-24T18:50:32.554Z] at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
[2024-01-24T18:50:32.554Z] 1: core::panicking::panic_fmt
[2024-01-24T18:50:32.554Z] at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
[2024-01-24T18:50:32.555Z] 2: tokio::runtime::context::runtime::enter_runtime
[2024-01-24T18:50:32.556Z] 3: tokio::runtime::runtime::Runtime::block_on
[2024-01-24T18:50:32.557Z] 4: RUST_BACKTRACE=full
for a verbose backtrace.
[2024-01-24T18:50:36.363Z] thread 'tokio-runtime-worker' panicked at src/main.rs:236:15:
[2024-01-24T18:50:36.363Z] Task panicked: Any { .. }
[2024-01-24T18:50:36.364Z] stack backtrace:
[2024-01-24T18:50:36.364Z] 0: rust_begin_unwind
[2024-01-24T18:50:36.364Z] at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
[2024-01-24T18:50:36.364Z] 1: core::panicking::panic_fmt
[2024-01-24T18:50:36.364Z] at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
[2024-01-24T18:50:36.364Z] 2: core::result::unwrap_failed
[2024-01-24T18:50:36.364Z] at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/result.rs:1652:5
[2024-01-24T18:50:36.364Z] 3: handler::get_data::{{closure}}
[2024-01-24T18:50:36.364Z] 4: <warp::filter::and_then::AndThenFuture<T,F> as core::future::future::Future>::poll
[2024-01-24T18:50:36.366Z] 5: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_loop
[2024-01-24T18:50:36.367Z] 6: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_catch
[2024-01-24T18:50:36.369Z] 7: <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll
[2024-01-24T18:50:36.369Z] 8: <hyper::server::server::new_svc::NewSvcTask<I,N,S,E,W> as core::future::future::Future>::poll
[2024-01-24T18:50:36.369Z] 9: tokio::runtime::task::core::Core<T,S>::poll
[2024-01-24T18:50:36.369Z] 10: tokio::runtime::task::harness::Harness<T,S>::poll
[2024-01-24T18:50:36.369Z] 11: tokio::runtime::scheduler::multi_thread::worker::Context::run_task
[2024-01-24T18:50:36.372Z] 12: tokio::runtime::scheduler::multi_thread::worker::run
[2024-01-24T18:50:36.372Z] 13: tokio::runtime::task::core::Core<T,S>::poll
[2024-01-24T18:50:36.372Z] 14: tokio::runtime::task::harness::Harness<T,S>::poll
[2024-01-24T18:50:36.375Z] note: Some details are omitted, run with RUST_BACKTRACE=full
for a verbose backtrace.
Hi @orlp. This is with Rust_Backtrace=full.
**Cannot start a runtime from within a runtime. This happens because a function (like block_on
) attempted to block the current thread while the thread is being used to drive asynchronous tasks.
thread '
I wasn't aware that Polars is using Rayon in backend for multithreading.
I met the same issue. and a workaround is like
let df = tokio::task::spawn_blocking(|| {
LazyFrame::scan_parquet("", args)
.unwrap()
.collect()
.unwrap()
}).await.unwrap();
it would be better if polars can offer async api?
and remove the tokio runtime wrapper in polars-io-0.37.0/src/cloud/glob.rs
#[tokio::main(flavor = "current_thread")]
/// List files with a prefix derived from the pattern.
pub async fn glob(url: &str, cloud_options: Option<&CloudOptions>) -> PolarsResult<Vec<String>> {
Can you confirm this is still an issue on main? We improved a lot lately.
@ritchie46, yes the problem still persists. Just encountered the exact same one with current master branch. The workaround from @Veiasai is also working for me.
Minimal example that fails:
#[tokio::test(flavor = "multi_thread")]
async fn fails() {
let path_string = OBJECT_STORE_BASE_URL.to_string() + "sample_parquet.snappy.parquet";
let path = Path::new(&path_string);
let lazy_frame = LazyFrame::scan_parquet(path, ScanArgsParquet::default())
.unwrap()
.count()
.collect()
.unwrap();
println!("{:?}", lazy_frame)
}
Checks
[X] I have checked that this issue has not already been reported.
[X] I have confirmed this bug exists on the latest version of Polars.
Reproducible example
Log output
Issue description
When running scan_parquet_files function inside async tokio function, polars starts to block the async main tokio function. The workaround for that is to put scan_parquet_files code inside a tokio::task::spawn_blocking block. It works most of the times but sometimes it throws the error that "cannot start runtime within a runtime". The issue very unpredictible. To reproduce the issue we might have to run somtimes 10 times the same code or sometimes within 1-2 runs this error comes up.
Expected behavior
Polars scan_parquet_files should not block async tokio runtime thread.
Installed versions