-
Notifications
You must be signed in to change notification settings - Fork 592
BlockingLayer
example in async context panics
#5857
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm guessing you need this because of the cache layer. However, this is not a good pattern and shouldn't happen. Operators with BlockingLayer should only be used in a blocking context, such as cross-language bindings. We can only implement CacheLayer for async operations. |
Perfect, thanks for your explanation! And about this |
Not a bug to fix, closing. |
Uh oh!
There was an error while loading. Please reload this page.
While working on #5678 I had the necessity of calling an
async
function within a sync function.I saw the
BlockingLayer
did something very similar of what I wanted in those two lines:opendal/core/src/layers/blocking.rs
Line 137 in fc767b2
and
opendal/core/src/layers/blocking.rs
Line 232 in fc767b2
However, when I tried the following
BlockingLayer
example atopendal/core/src/layers/blocking.rs
Line 43 in fc767b2
with the following main code based on that example:
It panicked with the following error:
It seems that using
Handle::current().block_on(..)
does not work propertly within async contexts... Or am I doing something wrong?I am trying to do something very similar at #5678 and I wonder what should be the correct approach in these cases
The text was updated successfully, but these errors were encountered: