Skip to content

Add implementation for wasi_thread_spawn()#1786

Merged
wenyongh merged 2 commits into
bytecodealliance:dev/wasi_threadsfrom
loganek:loganek/thread-implementation
Dec 13, 2022
Merged

Add implementation for wasi_thread_spawn()#1786
wenyongh merged 2 commits into
bytecodealliance:dev/wasi_threadsfrom
loganek:loganek/thread-implementation

Conversation

@loganek

@loganek loganek commented Dec 6, 2022

Copy link
Copy Markdown
Contributor

For now this implementation uses thread manager.

I wasn't sure whether thread manager is needed in that case. In the future there'll be likely another syscall added (for pthread_exit) and for that we might need some kind of thread management - with that in mind, I keep thread manager for now and we'll refactor this later if needed.

The parameter should be of type integer (i) instead of buffer; the native
code should never access the data pointed by the pointer, therefore having
the argument as a pointer requires additional unnecessary conversion.
@loganek loganek force-pushed the loganek/thread-implementation branch from ac51ca0 to 52fc95b Compare December 6, 2022 17:46
Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c
Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c Outdated
Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c Outdated
Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c Outdated
Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c Outdated
@loganek loganek force-pushed the loganek/thread-implementation branch 2 times, most recently from c0ba6ef to 4705265 Compare December 7, 2022 10:23
@loganek loganek mentioned this pull request Dec 7, 2022
19 tasks

@yamt yamt left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

lgtm

Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c Outdated
Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c Outdated
goto thread_spawn_fail;
}

thread_start_arg->thread_id = thread_id = allocate_thread_id();

@wenyongh wenyongh Dec 9, 2022

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Shall we check the integer overflow in allocate_thread_id? The system may run for long time and keep creating threads and eventually integer overflow occurs.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We're planning to improve thread id allocation strategy in the upcoming PRs, I left it like that for simplicity.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

besides that, wasi-libc doesn't seem to use this id for anything important (yet)

Comment thread core/iwasm/libraries/lib-wasi-threads/lib_wasi_threads_wrapper.c
@loganek loganek force-pushed the loganek/thread-implementation branch from 4705265 to 99b932d Compare December 9, 2022 12:16
#endif

#if WASM_ENABLE_LIB_WASI_THREADS != 0
if (!lib_wasi_threads_init())

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Should lib_wasi_threads_destroy() in the handling of fail if lib_wasi_threads_init() is called, e.g. L468, L476? And we should modify L483 to goto fail?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

lib_wasi_threads_destroy() is called in wasm_native_destroy() so I think that's fine. I agree that L483 should goto fail instead of returning, will update that.

This is a simple implementation for now; going forward we most likely won't
need to rely on thread manager as it doesn't provide much value in this
scenario.
@loganek loganek force-pushed the loganek/thread-implementation branch from 99b932d to e8842ee Compare December 13, 2022 09:36
{
shared_t data = { 0, 52 };
__wasi_errno_t err;
shared_t data = { 0, 52, -1 };

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
shared_t data = { 0, 52, -1 };
shared_t data = { .th_ready = 0, .value = 52, .thread_id = -1 };

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

iirc, we intentionally avoid designated initializers for some reasons. (old compilers?)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

yes, I think this is only available in >= c99

@wenyongh wenyongh merged commit 929d594 into bytecodealliance:dev/wasi_threads Dec 13, 2022
vickiegpt pushed a commit to vickiegpt/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
For now this implementation uses thread manager.

Not sure whether thread manager is needed in that case. In the future there'll be likely another syscall added (for pthread_exit) and for that we might need some kind of thread management - with that in mind, we keep thread manager for now and will refactor this later if needed.
@loganek loganek deleted the loganek/thread-implementation branch June 10, 2024 12:48
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.

4 participants