-
Notifications
You must be signed in to change notification settings - Fork 625
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
[instantiation linking] Refactor wasm_runtime_instantiate() #3893
base: dev/instantiate_linking
Are you sure you want to change the base?
[instantiation linking] Refactor wasm_runtime_instantiate() #3893
Conversation
4016457
to
36646a0
Compare
edddd11
to
f261840
Compare
- ~99% same with memory_instantiation() in wasm_runtime.c - new apis to create and destroy memory
…tantiation logic in wasm_runtime.c
The main goal is to let existed code run without modification
…ctor related import handling in thread management
f261840
to
b71bee8
Compare
core/iwasm/include/wasm_export.h
Outdated
|
||
WASM_RUNTIME_API_EXTERN void | ||
WASM_RUNTIME_API_EXTERN | ||
void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to have the return type on a separate line here?
@@ -300,15 +296,15 @@ memory_instantiate(const WASMModule *module, WASMModuleInstance *parent, | |||
uint8 *aux_heap_base_global_data, char *error_buf, | |||
uint32 error_buf_size) | |||
{ | |||
bh_assert(memory != NULL); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were sticking with declarations at the top of the block for compatibility with older C standards? This puts code before the declarations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After careful observation, I've come to understand that it is Ok to relax the restrictions on where variable declarations are placed. All the compilers and products we're aware of won't have an issue with this change. However, if you're aware of any exceptions, please inform me.
The benefit is clear. Code readability will improve if we move variable declarations closer to where they are used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, I am for this new approach.
|
||
total_size = sizeof(WASMMemoryInstance *) * (uint64)memory_count; | ||
|
||
if (!(memories = runtime_malloc(total_size, error_buf, error_buf_size))) { | ||
return NULL; | ||
} | ||
|
||
memory = module_inst->global_table_data.memory_instances; | ||
WASMMemoryInstance *memory = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as previous comment, are we ok with declarations not being at the top?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is addressed by the previous discussion.
@@ -11,6 +11,7 @@ find_path(WASISDK_HOME | |||
REQUIRED | |||
) | |||
|
|||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks extraneous?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved.
- Remove unnecessary blank line in FindWASISDK.cmake for improved readability - Format function declaration for wasm_runtime_destroy_imports for consistency
based #3845 and #3887