public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Max Carrara <m.carrara@proxmox.com>
To: Wolfgang Bumiller <w.bumiller@proxmox.com>
Cc: pbs-devel@lists.proxmox.com
Subject: Re: [pbs-devel] [PATCH proxmox] async: runtime: fix `block_in_place` panicking in wrong runtime
Date: Fri, 18 Aug 2023 11:57:36 +0200	[thread overview]
Message-ID: <4a4edb63-d67b-dc83-216b-719199d4582f@proxmox.com> (raw)
In-Reply-To: <fhmq4hldzc3degcomusmdyk3ucra3tum4qwjqykrm6r5x76kqt@7ev6pc4enl56>

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@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





      reply	other threads:[~2023-08-18  9:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 16:46 Max Carrara
2023-08-18  7:26 ` Wolfgang Bumiller
2023-08-18  9:57   ` Max Carrara [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a4edb63-d67b-dc83-216b-719199d4582f@proxmox.com \
    --to=m.carrara@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=w.bumiller@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal