Generic exceptions handling callback included

[borjatelladotecnalia]

In order to be able to catch "trap" errors from native side and reload the WAMR application or trigger corrective actions such as "reload factory settings" for us this type of notifications are very usefull. We took as reference the "enlarge memory exception" mechanism and try to keep it simple.

[yamt]

In order to be able to catch "trap" errors from native side and reload the WAMR application or trigger corrective actions such as "reload factory settings" for us this type of notifications are very usefull. We took as reference the "enlarge memory exception" mechanism and try to keep it simple.

i don't see what's the point of the api.
an embedder can use wasm_runtime_get_exception to handle traps.

[borjatelladotecnalia]

In order to be able to catch "trap" errors from native side and reload the WAMR application or trigger corrective actions such as "reload factory settings" for us this type of notifications are very usefull. We took as reference the "enlarge memory exception" mechanism and try to keep it simple.

i don't see what's the point of the api. an embedder can use wasm_runtime_get_exception to handle traps.

Our use case is more or less the following: A native embedded application written in C, running on ThreadX RTOS, embeds a WAMR runtime to execute a WebAssembly module in the background. The WASM module exports functions used by the native application to enqueue/push data. The WASM module periodically computes results in its dedicated thread. If invalid data or processing errors occur, a native callback function is invoked directly from the WASM runtime environment to notify the host system

Functional Flow:

1. Initialization:

   • Native code starts wasm_thread, sets up the WASM runtime, and loads the module.
   • A C function pointer (the callback) is registered as a host function import, exposed to the WASM side.

2. Data Input:

   • Native app calls exported WASM functions to pass data (e.g., via enqueue_value(data)).

3. Computation Cycle:

   • The WASM module sleeps or waits for a time slice (every n seconds), then processes the buffered input.

4. Error Detection and Callback Trigger:

   • If the input state is invalid or a computation fails:
     • The WASM code calls an imported host function (the registered C callback).
     • The native-side callback is invoked from within the WASM thread context.
     • This function may log the error, update system state, or trigger recovery actions.

What we need is to stop the WASM module when an error occurs and notify the native side. The native application is unaware of the internal behavior of the WASM module, which runs autonomously in the background. As I understand it (though I may be wrong), using wasm_runtime_get_exception would require the native side to poll the WASM module, which doesn't fit our use case.

[yamt]

In order to be able to catch "trap" errors from native side and reload the WAMR application or trigger corrective actions such as "reload factory settings" for us this type of notifications are very usefull. We took as reference the "enlarge memory exception" mechanism and try to keep it simple.

i don't see what's the point of the api. an embedder can use wasm_runtime_get_exception to handle traps.

Our use case is more or less the following: A native embedded application written in C, running on ThreadX RTOS, embeds a WAMR runtime to execute a WebAssembly module in the background. The WASM module exports functions used by the native application to enqueue/push data. The WASM module periodically computes results in its dedicated thread. If invalid data or processing errors occur, a native callback function is invoked directly from the WASM runtime environment to notify the host system

Functional Flow:

1. **Initialization:**
   
   * Native code starts `wasm_thread`, sets up the WASM runtime, and loads the module.
   * A C function pointer (the callback) is registered as a host function import, exposed to the WASM side.

2. **Data Input:**
   
   * Native app calls exported WASM functions to pass data (e.g., via `enqueue_value(data)`).

3. **Computation Cycle:**
   
   * The WASM module sleeps or waits for a time slice (every _n_ seconds), then processes the buffered input.

4. **Error Detection and Callback Trigger:**
   
   * If the input state is invalid or a computation fails:
     
     * The WASM code calls an imported host function (the registered C callback).
     * The native-side callback is invoked from within the WASM thread context.
     * This function may log the error, update system state, or trigger recovery actions.

What we need is to stop the WASM module when an error occurs and notify the native side. The native application is unaware of the internal behavior of the WASM module, which runs autonomously in the background. As I understand it (though I may be wrong), using wasm_runtime_get_exception would require the native side to poll the WASM module, which doesn't fit our use case.

wasm_runtime_get_exception is expected to be used after an api call to execute wasm bytecode returns.
eg.

wasm_application_execute_main(... );
if (wasm_runtime_get_exception(... )) {
  // got an exception, call your handler.
}

note that thread-mgr propagates the exception to every threads in the group. (cf. wasm_cluster_set_exception)

[borjatelladotecnalia]

In order to be able to catch "trap" errors from native side and reload the WAMR application or trigger corrective actions such as "reload factory settings" for us this type of notifications are very usefull. We took as reference the "enlarge memory exception" mechanism and try to keep it simple.

i don't see what's the point of the api. an embedder can use wasm_runtime_get_exception to handle traps.

Our use case is more or less the following: A native embedded application written in C, running on ThreadX RTOS, embeds a WAMR runtime to execute a WebAssembly module in the background. The WASM module exports functions used by the native application to enqueue/push data. The WASM module periodically computes results in its dedicated thread. If invalid data or processing errors occur, a native callback function is invoked directly from the WASM runtime environment to notify the host system
Functional Flow:

1. **Initialization:**
   
   * Native code starts `wasm_thread`, sets up the WASM runtime, and loads the module.
   * A C function pointer (the callback) is registered as a host function import, exposed to the WASM side.

2. **Data Input:**
   
   * Native app calls exported WASM functions to pass data (e.g., via `enqueue_value(data)`).

3. **Computation Cycle:**
   
   * The WASM module sleeps or waits for a time slice (every _n_ seconds), then processes the buffered input.

4. **Error Detection and Callback Trigger:**
   
   * If the input state is invalid or a computation fails:
     
     * The WASM code calls an imported host function (the registered C callback).
     * The native-side callback is invoked from within the WASM thread context.
     * This function may log the error, update system state, or trigger recovery actions.

What we need is to stop the WASM module when an error occurs and notify the native side. The native application is unaware of the internal behavior of the WASM module, which runs autonomously in the background. As I understand it (though I may be wrong), using wasm_runtime_get_exception would require the native side to poll the WASM module, which doesn't fit our use case.

wasm_runtime_get_exception is expected to be used after an api call to execute wasm bytecode returns. eg.

wasm_application_execute_main(... );
if (wasm_runtime_get_exception(... )) {
  // got an exception, call your handler.
}

note that thread-mgr propagates the exception to every threads in the group. (cf. wasm_cluster_set_exception)

Well, I think that I found the origin of my missunderstanding, at the begining of our project I used to test with the structure described above and tried some "trapy" code.

 6  float div_to_zero (int value, int div_value)
  7 {
  8     float new_value = value / div_value;
  9     printf ("Divsion done %d",div_value);
 10     return new_value;
 11 }

 57 int main(int argc, char **argv)
 58 {
 59     for (int i = 0 ; i < 15;i++)
 60         div_to_zero(10, (10-i));
 61     printf ("\nAll divisions done\n");
 65     return 0;
 66 }

It seems that if the code is compiled with the -O3 clang flag, the compiler is wise enough to "strip" the line (#8) when i=10 and the exception calculating the new_value (line 8) is not triggered and the execution is not stopped, on the other hand if compiled with -O0 the exception is triggered and the execution is stopped.

[lum1n0us]

Great. It seems there is no need to discuss this PR any further. Let's close it.

[lum1n0us]

Great. It seems there is no need to discuss this PR any further. Let's close it.