Skip to content

multi-process support for dynamic loading#911

Open
qianxichen233 wants to merge 4 commits intodylink_impl_integrationfrom
dylink_impl_multi_process
Open

multi-process support for dynamic loading#911
qianxichen233 wants to merge 4 commits intodylink_impl_integrationfrom
dylink_impl_multi_process

Conversation

@qianxichen233
Copy link
Contributor

multi-process/multi-threads/signal support for dynamic loading

still pretty messy right now, raise the PR right now in case anyone needs to check/use this branch

// let stack_pointer = instance.get_stack_pointer(store.as_context_mut()).unwrap();
let stack_low = 0;
let stack_pointer = 0;
let stack_low = 1024;
Copy link
Contributor

Choose a reason for hiding this comment

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

lets define constants and not use magic numbers

pub fn fork_call(&self, mut caller: &mut Caller<'_, T>, child_cageid: u64) -> Result<i32> {
// get the base address of the memory
let handle = caller.as_context().0.instance(InstanceId::from_index(0));
let handle = caller.as_context().0.instance(InstanceId::from_index(1));
Copy link
Contributor

Choose a reason for hiding this comment

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

also fragile with magic numbers (this is a couple places) need to use constants, or lookup by name?

//
// `allow_shadowing(true)` permits redefining these globals in the cloned
// linker without affecting the original linker state.
self.allow_shadowing(true);
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm calling self.allow_shadowing(true) before cloning. In the parent module() method, this was deliberately moved to only apply to the cloned module_linker. Mutating the original linker's shadowing policy is likely unintended and could cause definition collisions in the parent.

@rennergade
Copy link
Contributor

I think longjmp is still disabled?

Also theres some overlap between fork and threads: The child table creation + library module re-linking loop is essentially copy-pasted. This should be extracted into a helper method (e.g., setup_child_modules).

Will give more comments when you come back to this

@vidyalakshmir
Copy link
Contributor

vidyalakshmir commented Mar 11, 2026

@qianxichen233 I tried building after checkout of this branch, but get this error

error[E0599]: no method named `get_id` found for reference `&externals::Extern` in the current scope
    --> /home/lind/lind-wasm/src/wasmtime/crates/wasmtime/src/runtime/linker.rs:1978:19
     |
1978 |                 e.get_id()
     |                   ^^^^^^ method not found in `&externals::Extern`

@qianxichen233
Copy link
Contributor Author

@qianxichen233 I tried building after checkout of this branch, but get this error

error[E0599]: no method named `get_id` found for reference `&externals::Extern` in the current scope
    --> /home/lind/lind-wasm/src/wasmtime/crates/wasmtime/src/runtime/linker.rs:1978:19
     |
1978 |                 e.get_id()
     |                   ^^^^^^ method not found in `&externals::Extern`

delete this line. It is part of debug changes. I am not pushing all the debug changes but this line seems to be pushed accidentally

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