pyo3 kyle Q&A #506
Replies: 3 comments 6 replies
|
The Python GIL does not negate the benefits of the tokio runtime as long as the Rust tasks are longer than the Python tasks. The Python tasks are extremely lightweight futures that just represent when the heavier Rust tasks finish. But I would like to make it user configurable how many cores tokio should use (or just better document the environment variable tokio uses to choose how many cores to use in the threadpool) |
|
Misc question: In the fn validate_buffer(buf: &PyBuffer<u8>) -> PyResult<()> {
if !buf.is_c_contiguous() {
return Err(PyValueError::new_err("Buffer is not C contiguous"));
}
if buf.strides().iter().any(|s| *s != 1) {
return Err(PyValueError::new_err(format!(
"strides other than 1 not supported, got: {:?} ",
buf.strides()
)));
}
Ok(())
} |
|
Hi @kylebarron Have you played with different global allocators for obstore? if so what were you findings? PS: I changed this discussions name |
Uh oh!
There was an error while loading. Please reload this page.
Howdy @kylebarron,
I was just curious if you have experimented with single vs multi threaded tokio runtimes and if so, did you find anything interesting?
Maybe a dumb question, but does the python gil negate the benefits of the tokio runtime?
Best,
jesse
All reactions