Is it possible to avoid syscalls during Function::call?

[ul]

Summary

This question is in the context of using WASM for realtime audio synthesis. I invoke Function::call within an audio thread 48000 times per second. In the profiler, sigprogmask and sigaltstack get a noticeable share of CPU time (see attached screenshot). While overhead itself is more or less acceptable as it stays constant with the growth of the executed WASM code, the unpredictability of the latency incurred by syscalls is bothersome for my use-case, I get a high variation in the trace with some calls taking longer than my per-frame budget. So my question is as follows: is it possible to implement Function::call without the need for syscalls?

Additional details

[syrusakbary]

As functions can fail, we need to wrap them so if they fail we catch the traps properly.
However, this "catch" mechanism is done each time per function call and can indeed be optimized.

A few months ago we were thinking on creating an unsafe function call_unchecked so the user can catch errors themselves manually (rather than having Wasmer do it for them).
In your use case that means that you will choose how to catch the error. And you could save the 918ms spent on the traphandlers code.

How this would be implemented?

We would need a function similar to:

// Similar to wasmer_call_trampoline, but without catch_traps
pub unsafe fn wasmer_call_trampoline_unchecked(
    vmctx: VMFunctionEnvironment,
    trampoline: VMTrampoline,
    callee: *const VMFunctionBody,
    values_vec: *mut u8,
) -> Result<(), Trap> {
    mem::transmute::<_, extern "C" fn(VMFunctionEnvironment, *const VMFunctionBody, *mut u8)>(
        trampoline,
    )(vmctx, callee, values_vec)
}

And then the user would need to do something similar to:

catch_traps(vmctx, || {
    for i in 1..48000 {
        unsafe {
            func.call_unchecked(...);
        }
    }
}

This way, catch_traps will only be called once rather than 48,000 times and our code will still be safe to execute (returning any error when it happens.

[ul]

Thank you for the explanation @syrusakbary! Indeed it would be nice to have such flexible API for traps to allow for some optimisations in cases like mine.

[syrusakbary]

Hi @ul,

I just created #2102. It should address your main question as it makes Function calls an order of magnitude faster.

[ul]

Thank you, I appreciate it!

[syrusakbary]

Duplicate of #2562