IpcMain : add support for async callbacks #386

duncanawoods · 2020-03-31T21:49:23Z

Callbacks triggered by the UI are async (with respect to the web UI) but are handled with a non-async C# action:

Electron.IpcMain.On(string channel, Action<object> listener)

It is now common for C# controller methods to be async so it would be convenient to support them directly with the following overload i.e.

Electron.IpcMain.On(string channel, Func<object, Task> listener)

Bridging the sync -> async boundary, might just mean using Task.Run but I don't know whether running it on the threadpool is actually optimal because I assume On is already being invoked on it's own thread. By implementing this API, hopefully you are able to make the right choice about how to execute the async method without adding unnecessary overhead.

//
// Is invoking on the threadpool ideal?
//
public void On(string channel, Func<object, Task> listener) =>
    this.On(
        channel, 
        args => Task.Run(async () => await listener(args)));

GregorBiswanger · 2020-04-17T22:51:56Z

The callback is Async. Use with Async-Await is also possible if you execute asynchronous code in the callback.

Or did I misunderstand you?

yawnston · 2020-04-18T12:57:51Z

While it is technically possible to use async-await in the callback, if the callback produces an exception then this exception will be completely ignored since the Task would not be awaited. What @duncanawoods is proposing unfortunately doesn't seem like the solution either since Task.Run itself returns a Task which would not be awaited, so it seems like it's just shifting the problem 1 level deeper.

I actually did a little bit of digging and it looks like supporting this wouldn't be such an easy fix, since the Quobject.SocketIoClientDotNet library used by Electron.NET doesn't seem to support awaiting async callbacks on its Socket class. Sidenote is that the mentioned Socket.IO client library is deprecated and not maintained anymore, so maybe if this project decides to switch its Socket.IO client library, this issue could be solved at the same time. This issue (Quobject/EngineIoClientDotNet#69) discusses some client library alternatives.

Right now I think the only workaround would be to just block on the Func<object, Task> listener. That might be okay considering this library is only meant to be used from ASP.NET Core anyway, but it's still probably a better idea to leave it as it is for now. Blocking on async code gives me the jitters.

GregorBiswanger · 2020-04-20T12:53:10Z

I am currently working on version 8.31.1 - Trying a completely different Socket.IO .NET client will be a bit short of time ... I will be the father of my second son in early May and will be somewhat limited .. if necessary someone has try another Socket.IO client from the community time ..

duncanawoods · 2020-04-20T14:05:19Z

@yawnston

if the callback produces an exception

In most GUI APIs, an unhandled exception in a callback is application fatal. It would be normal for a callback to encapsulate it's errors rather than bubble them up to a framework that can't do anything sensible with them.

doesn't seem like the solution either since Task.Run itself returns a Task which would not be awaited

Task.Run returns a task but it doesn't need to be awaited unless you wish to capture the result or block until the asynchronous execution on the thread-pool is complete. Neither of these are relevant for supplying a callback.

A real reason this and other such workarounds that try to force async code to be executed by a sync framework, should be avoided, is deadlock.

dafergu2 · 2020-05-18T02:20:01Z

I snooped around a little on this. Perhaps looking at this as a replacement would be good?

https://github.com/HavenDV/H.Socket.IO/

At the very least, the replies back to the electron main process can use async/await. I'd want to dive into it a bit to see if the callbacks can accept an async method as well.

duncanawoods added the Feature label Mar 31, 2020

GregorBiswanger self-assigned this Apr 17, 2020

GregorBiswanger added the help wanted label Apr 20, 2020

ElectronNET / Electron.NET

IpcMain : add support for async callbacks #386

IpcMain : add support for async callbacks #386

duncanawoods commented Mar 31, 2020 •

edited

GregorBiswanger commented Apr 17, 2020

yawnston commented Apr 18, 2020 •

edited

GregorBiswanger commented Apr 20, 2020

duncanawoods commented Apr 20, 2020 •

edited

dafergu2 commented May 18, 2020

ElectronNET / Electron.NET

Sponsor ElectronNET/Electron.NET

Join GitHub today

IpcMain : add support for async callbacks #386

IpcMain : add support for async callbacks #386

Comments

duncanawoods commented Mar 31, 2020 • edited

GregorBiswanger commented Apr 17, 2020

yawnston commented Apr 18, 2020 • edited

GregorBiswanger commented Apr 20, 2020

duncanawoods commented Apr 20, 2020 • edited

dafergu2 commented May 18, 2020

duncanawoods commented Mar 31, 2020 •

edited

yawnston commented Apr 18, 2020 •

edited

duncanawoods commented Apr 20, 2020 •

edited