Fix thread manager issues #962
Conversation
Merge bytecodealliance:main into wenyongh:main
| node = bh_list_elem_next(node); | ||
| } | ||
|
|
||
| cluster = bh_list_elem_next(cluster); |
There was a problem hiding this comment.
should we search the whole cluster list?
Seems we should only search the current cluster, otherwise we may get some thread of other wasm instance?
There was a problem hiding this comment.
But how to search the current cluster? Seems that we can only get it from exec_env->cluster, right? But if the exec_env has been removed from cluster and destroyed, accessing exec_env will cause crash.
How about, when a cluster is found that it contains the exec_env, then we check whether exec_env->cluster == cluster again? To ensure that the exec_env belongs to that cluster?
There was a problem hiding this comment.
How about, when a cluster is found that it contains the exec_env, then we check whether exec_env->cluster == cluster again? To ensure that the exec_env belongs to that cluster?
Sounds reasonable, and I think an assert is enough because this should never happen, when it really happens, that means the whole system is in an unstable state
Fix the issue that joining a detached thread might result in joining hang, resolve the issue by adding wait_count for a thread's exec_env to indicate whether a thread needs to detach itself or not when it exits. And add checks for the input exec_env for cluster's join/detach/cancel thread.
2 participants
Fix the issue that possibly joining a thread after it was detached which
might causes joining hang, by adding wait_count to indicate whether
a thread needs to detach itself or not when it exits.
Add checks for the input exec_env for cluster's join/detach/cancel thread.