[pbs-devel] [PATCH proxmox] async: runtime: fix `block_in_place` panicking in wrong runtime
Max Carrara
m.carrara at proxmox.com
Fri Aug 18 11:57:36 CEST 2023
On 8/18/23 09:26, Wolfgang Bumiller wrote:
> Does a single threaded runtime support `.spawn_blocking()`? Maybe it
> would make sense to use that in this case?
>
It does, yes!
However, we can't actually use `spawn_blocking()` inside our
`block_in_place()` wrapper; the former is async, the latter is sync.
So, I'll think of some other alternatives.
Maybe some additional helpers would work instead? Something like:
fn try_block_in_place<F, R>(func: F) -> Result<R, F>
where
F: FnOnce() -> R
{
...
}
Basically returning the original closure if
`tokio::task::block_in_place()` cannot be called.
> Because this just seems a tiny bit dangerous.
> Then again, `block_in_place` is the wrong helper if the blocking
> operation also depends on any futures making progress, it should only be
> used for independent operations... but that doesn't mean it can't
> accidentally happen somehow...
I'm not sure there's any way to prevent this from happening
accidentally. Maybe we can document this to make it apparent when
`block_in_place()` is appropriate and when it isn't? I'd include that
in the v2 in that case.
FWIW, there's a way[0] to re-enter an async context while within
`block_in_place()` using `Handle::block_on()`[1]:
use tokio::task;
use tokio::runtime::Handle;
task::block_in_place(move || {
Handle::current().block_on(async move {
// do something async
});
});
This isn't really ideal either imo (because why block when you depend
on other futures? There are better ways to do that) but I guess it's
useful to know.
[0]:
https://docs.rs/tokio/latest/tokio/task/fn.block_in_place.html#examples
[1]:
https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.block_on
> Ideally we could get rid of all the block-in-place stuff without slowing
> things down too much, but the latter part is difficult :-)
>
> On Thu, Aug 17, 2023 at 06:46:37PM +0200, Max Carrara wrote:
>> Because `tokio::task::block_in_place` panics if called in the
>> "current_thread" runtime, so does our wrapper function.
>>
>> This is fixed by checking whether we're actually in a multithreaded
>> tokio runtime.
>>
>> Signed-off-by: Max Carrara <m.carrara at proxmox.com>
>> ---
>> proxmox-async/src/runtime.rs | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/proxmox-async/src/runtime.rs b/proxmox-async/src/runtime.rs
>> index 0fe9fae..35cf7c3 100644
>> --- a/proxmox-async/src/runtime.rs
>> +++ b/proxmox-async/src/runtime.rs
>> @@ -15,7 +15,12 @@ thread_local! {
>> }
>>
>> fn is_in_tokio() -> bool {
>> - tokio::runtime::Handle::try_current().is_ok()
>> + tokio::runtime::Handle::try_current().is_ok_and(|rt_handle| {
>> + matches!(
>> + rt_handle.runtime_flavor(),
>> + tokio::runtime::RuntimeFlavor::MultiThread
>> + )
>> + })
>> }
>>
>> fn is_blocking() -> bool {
>> --
>> 2.39.2
More information about the pbs-devel
mailing list