diff --git a/doc/export_native_api.md b/doc/export_native_api.md
index b87d925522..e293e5c0d7 100644
--- a/doc/export_native_api.md
+++ b/doc/export_native_api.md
@@ -261,4 +261,32 @@ wasm_response_send(wasm_exec_env_t exec_env, char *buffer, int size)
 ```
 
 
-
+## Native API implementation notes
+
+### Async thread termination
+
+When threading support is enabled, a thread can be requested to terminate
+itself either explicitly by the `wasm_runtime_terminate` API or implicitly
+by cluster-wide activities like WASI `proc_exit`.
+If a call to your native function can take long or even forever,
+you should make it to respond to termination requests in a timely manner.
+There are a few implementation approaches for that:
+
+* Design your API so that it always returns in a timely manner.
+  This is the most simple approach when possible.
+
+* Make your native function check the cluster state by calling
+  `wasm_cluster_is_thread_terminated` from time to time.
+  If `wasm_cluster_is_thread_terminated` returns true, make your
+  native function return.
+  Note: as of writing this, `wasm_cluster_is_thread_terminated` is not
+  exported as a runtime API.
+
+* If your native function is a simple wrapper of blocking system call,
+  you can probably use the `wasm_runtime_begin_blocking_op` and
+  `wasm_runtime_end_blocking_op` runtime API.
+  See the comment in `wamr_export.h` for details.
+
+* If your native function is very complex, it might be simpler to put the
+  guts of it into a separate worker process so that it can be cleaned up
+  by simply killing it.