Currently, the generated adapter code for .NET delegates automatically switches to the JS thread when .NET code calls the JS function. But, collection adapters and generated interface adapters do not. In most cases it's not a problem because the JSSynchronizationContext causes awaits to return to the JS thread. But this can be a problem if the application does explicit threading, or when the interface or collection is passed to library code that (correctly) uses ConfigureAwait(false) to prevent await from returning to the JS thread.
We should consider having all of these adapters switch to the JS thread automatically, if it can be done safely (without causing deadlocks) and without significantly hurting performance. Or if/when they cannot switch, they should report an informative error message.
Currently, the generated adapter code for .NET delegates automatically switches to the JS thread when .NET code calls the JS function. But, collection adapters and generated interface adapters do not. In most cases it's not a problem because the
JSSynchronizationContextcausesawaits to return to the JS thread. But this can be a problem if the application does explicit threading, or when the interface or collection is passed to library code that (correctly) usesConfigureAwait(false)to preventawaitfrom returning to the JS thread.We should consider having all of these adapters switch to the JS thread automatically, if it can be done safely (without causing deadlocks) and without significantly hurting performance. Or if/when they cannot switch, they should report an informative error message.