Add API for disabling native stack boundary checks

[loganek]

This API can be helpful if e.g. module is working in a reactor mode, and the module is being used from multiple threads (where the caller guarantees that no two threads execute code on the same execution environment). Currently this usecase fails because the native stack boundaries for each thread are different.

Alternative to this solution would be to update the boundary on every thread switch but that might not be desired due to performance.

I've added a new API but just having a logic for UINTPTR_MAX and using wasm_runtime_set_native_stack_boundary would be good enough. If the preference is to not have a new API, I'm ok to remove it and add a comment in the wasm_runtime_set_native_stack_boundary about the special UINTPTR_MAX value.

[lum1n0us]

LGTM w/ minor comments.

Update the comments for user_native_stack_boundary in the WASMExecEnv in wasm_exec_env.h to reflect the specific value accurately.

[yamt]

This API can be helpful if e.g. module is working in a reactor mode, and the module is being used from multiple threads (where the caller guarantees that no two threads execute code on the same execution environment). Currently this usecase fails because the native stack boundaries for each thread are different.

what you really want is an api to stop associating exec env to a host thread, right?
native stack boundary check is merely an example of possible functionalities which might rely on the association to a host thread.

Alternative to this solution would be to update the boundary on every thread switch but that might not be desired due to performance.

have you measured the performance?

[loganek]

what you really want is an api to stop associating exec env to a host thread, right?
native stack boundary check is merely an example of possible functionalities which might rely on the association to a host thread.

Yes, indeed. And I agree best way to do it by not tying the exec env to the thread. This is however a bit of extra work that we might do later but the native boundary check is currently the only blocker (from my usecase perspective) to apply a workaround.

The proposed change is generic enough and not strictly for my own usecase, so even though there are better ways to solve my particular problem, it shouldn't impact the WAMR architecture.

[yamt]

what you really want is an api to stop associating exec env to a host thread, right?
native stack boundary check is merely an example of possible functionalities which might rely on the association to a host thread.

Yes, indeed. And I agree best way to do it by not tying the exec env to the thread. This is however a bit of extra work that we might do later but the native boundary check is currently the only blocker (from my usecase perspective) to apply a workaround.

The proposed change is generic enough and not strictly for my own usecase, so even though there are better ways to solve my particular problem, it shouldn't impact the WAMR architecture.

by providing this api for this purpose, we effectively give a promise "disabling native stack boundary check via this api makes it safe to switch calling threads" to the api users, don't we?

your alternative solution ("update the boundary on every thread switch") looks simpler and more straightforward to me.

[loganek]

by providing this api for this purpose, we effectively give a promise "disabling native stack boundary check via this api makes it safe to switch calling threads" to the api users, don't we?

No, we should never officially state that by doing it users are enabled to switch calling threads, even though that might be the case. If users choose to do that, they do it at their own risk; the API's intention is to disable the native stack boundary checks, no more than that.

your alternative solution ("update the boundary on every thread switch") looks simpler and more straightforward to me.

Please note that this also needs a new API; also I think that more explicitly tells user that the API can be used for switching calling threads than what we have in this PR (because otherwise I think there's very few usecases for changing the stack boundary during a single-threaded execution).

[yamt]

by providing this api for this purpose, we effectively give a promise "disabling native stack boundary check via this api makes it safe to switch calling threads" to the api users, don't we?

No, we should never officially state that by doing it users are enabled to switch calling threads, even though that might be the case. If users choose to do that, they do it at their own risk; the API's intention is to disable the native stack boundary checks, no more than that.

well, in that case, i'm not sure why a user would want to disable the native stack boundary check.

your alternative solution ("update the boundary on every thread switch") looks simpler and more straightforward to me.

Please note that this also needs a new API; also I think that more explicitly tells user that the API can be used for switching calling threads than what we have in this PR (because otherwise I think there's very few usecases for changing the stack boundary during a single-threaded execution).

yes. maybe a "disassociate from the calling thread" api.

[loganek]

by providing this api for this purpose, we effectively give a promise "disabling native stack boundary check via this api makes it safe to switch calling threads" to the api users, don't we?

No, we should never officially state that by doing it users are enabled to switch calling threads, even though that might be the case. If users choose to do that, they do it at their own risk; the API's intention is to disable the native stack boundary checks, no more than that.

well, in that case, i'm not sure why a user would want to disable the native stack boundary check.

your alternative solution ("update the boundary on every thread switch") looks simpler and more straightforward to me.

Please note that this also needs a new API; also I think that more explicitly tells user that the API can be used for switching calling threads than what we have in this PR (because otherwise I think there's very few usecases for changing the stack boundary during a single-threaded execution).

yes. maybe a "disassociate from the calling thread" api.

Yes, that's a completely different API and would need to do more than just dealing with boundary checks. Having said that, Setting the stack boundary to 0x01 (which is possible today) is good enough for me so if there's a strong objection for adding an option to disable the stack boundary checks, can don't mind closing the PR.

[lum1n0us]

@yamt @wenyongh @TianlongLiang @xujuntwt95329 Please let us know your thoughts. Should we proceed with merging or closing the pull request?

[yamt]

@yamt @wenyongh @TianlongLiang @xujuntwt95329 Please let us know your thoughts. Should we proceed with merging or closing the pull request?

i prefer not to merge this as there seems to be no real use cases.

what the author wants to do is kinda abuse of the new proposed api.
also, the author has another way to achieve his goal as he said. (wasm_runtime_set_native_stack_boundary)

[xujuntwt95329]

The use case @loganek mentioned is very common, the introduced API in this PR is an interesting approach to meet the requirement.
However, I agree with @yamt that the API itself doesn't explicitly explain its real use case, this may cause confusion. So in my opinion, I think it's not reasonable to add this API. If we want to explicitly detach a thread environment, we had better design a dedicated API for it.