With TransitFunction#callAsync there's already a way to express async calls (back to JS) that do not expect a result. That's especially needed to break an otherwise deep recursion in scenarios where JS calls native functions in a callback.
But, the naïve implementation on Objective-C simple schedules a call of [callWithThisArg:arguments:returnResult:NO] into the future, at the moment. While this returns immediately, it will produce a blocking call to the JS-Environment for each callAsync at a later point in time.
A more efficient implementation should collect async JS-Calls in a queue and perform a single call to the JS-Environment when this queue will be handled.
With
TransitFunction#callAsyncthere's already a way to express async calls (back to JS) that do not expect a result. That's especially needed to break an otherwise deep recursion in scenarios where JS calls native functions in a callback.But, the naïve implementation on Objective-C simple schedules a call of
[callWithThisArg:arguments:returnResult:NO]into the future, at the moment. While this returns immediately, it will produce a blocking call to the JS-Environment for eachcallAsyncat a later point in time.A more efficient implementation should collect async JS-Calls in a queue and perform a single call to the JS-Environment when this queue will be handled.
Also, see #11 for the opposite direction.