Skip to content
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

wasm: clean up the code #36556

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Conversation

wbpcode
Copy link
Member

@wbpcode wbpcode commented Oct 12, 2024

Commit Message: wasm: clean up the code
Additional Description:

When I doing the #36456, I found there are lots of redundant code in the wasm extensions. And the wasm loading and creations are spread out in multiple different positions.
This redundancy and fragmentation make #36456 become more and more complex.

Finally, I split the code clean up out as an independent PR.

This PR doesn't change any logic but only merge duplicated logic.

Risk Level: n/a.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.

Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Copy link
Contributor

@kyessenov kyessenov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but not 100% if code is exactly the same. I can take a look again.


plugin_ = std::make_shared<Plugin>(config, direction, context.localInfo(), metadata);

auto callback = [this, &context](WasmHandleSharedPtr base_wasm) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: maybe put ASSERT_MAIN_OR_TEST_THREAD?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thanks.

init_manager, context.mainThreadDispatcher(), context.api(),
context.lifecycleNotifier(), remote_data_provider_,
std::move(callback))) {
throw Common::Wasm::WasmException(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we restructure this to avoid exceptions?

Copy link
Member Author

@wbpcode wbpcode Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great suggestion.

Copy link
Member Author

@wbpcode wbpcode Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I finally add a TODO first. Because this is in the constructor and we need to use creation_status to handle the error. That means we need to change code of lots of different positions at where this PluginConfig is used.

We can put it to separated PR.


if (is_singleton_handle_) {
// Use critical log because this error should not happen in production.
ENVOY_LOG(critical, "CreateContext() only works for thread local plugins.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not release assert if this never should be called by the implementation?

Copy link
Member Author

@wbpcode wbpcode Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is finally removed at #36456. Finally, we use the same way to treat the singleton handle and thread local handle.
So, I think we can leave it there for now?

return singleton_handle_ != nullptr ? singleton_handle_->wasmOfHandle() : nullptr;
}

ASSERT(thread_local_handle_ != nullptr);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RELEASE_ASSERT since it would crash anyways?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the current code base, seems we prefer the ASSERT even in this type case? Let's me know if you think this is a block point.

Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants