There is a reason why not to use "BridgeConnector.Socket.Once"?

[Denny09310]

I've noticed throughout the codebaese a lot of instances like this one:

public Task<Point> GetCursorScreenPointAsync()
{
    var taskCompletionSource = new TaskCompletionSource<Point>();

    BridgeConnector.Socket.On<Point>("screen-getCursorScreenPointCompleted", (point) =>
    {
        BridgeConnector.Socket.Off("screen-getCursorScreenPointCompleted");
        taskCompletionSource.SetResult(point);
    });

    BridgeConnector.Socket.Emit("screen-getCursorScreenPoint");

    return taskCompletionSource.Task;
}

Why this can't be translated into:

public Task<Point> GetCursorScreenPointAsync()
{
    var taskCompletionSource = new TaskCompletionSource<Point>();

    BridgeConnector.Socket.Once<Point>("screen-getCursorScreenPointCompleted", taskCompletionSource.SetResult);
    BridgeConnector.Socket.Emit("screen-getCursorScreenPoint");

    return taskCompletionSource.Task;
}

There is a specific reason not to do so?

[FlorianRappl]

My guess is that Once may not have been available historically.

Otherwise you are right - Once should be used.

[Denny09310]

Thanks for the quick response! I could have a separate branch where I apply this change

[FlorianRappl]

Yes, would be appreciated. I've just merged the last one into develop - that should prevent any merge conflicts / allow you to use the System.Text.Json improvements to use as a basis.

[softworkz]

I would advise agains making that change right now.

We have seen that SocketIO does not synchronize access to its event registration dictionary. My recent PR adds explicit locking, but this would get undermined when SocketIO does the removal internally, because this operation won't be subject to our locking.

[softworkz]

Sorry, please scratch my comment. I thought we're talking aboute a .Once() method in SocketIO, not our own one.

But since it's about our own one, we can indeed use it (little fix for locking here: #921)