You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A non-blocking API would be great. The crate is not that ergonomic to use in a project that relies on the tokio runtime. This is due to the fact that you can not spawn a tokio::Runtime from within a runtime.
thread 'key_manager::tests::test_construction' panicked at '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.'
Also, dyn <Primitive> are cumbersome without Send + Sync.
/// Returns a [`tink_core::Aead`] primitive from the given keyset handle.pubfnnew(h:&tink_core::keyset::Handle) -> Result<Box<dyn tink_core::Aead>,TinkError>{new_with_key_manager(h,None)}
I can get around the first issue with an actor and spawning a thread, but lack of Send + Sync on the primitives is a tough one.
I believe there are a few changes that would need to be made:
Create a feature flag, something like "non-blocking" to avoid breaking changes.
A non-blocking API would be great. The crate is not that ergonomic to use in a project that relies on the tokio runtime. This is due to the fact that you can not spawn a
tokio::Runtime
from within a runtime.Also,
dyn <Primitive>
are cumbersome withoutSend + Sync
.I can get around the first issue with an actor and spawning a thread, but lack of
Send + Sync
on the primitives is a tough one.I believe there are a few changes that would need to be made:
AeadEnvelope
trait:dyn <Primitive>
will likely need to bedyn 'static + <Primitive> + Send + Sync
Thank you for your work and effort porting this.
The text was updated successfully, but these errors were encountered: