tejacques/asyncbridge

A library to help bridge C# async method execution from synchronous methods, such as in Windows Forms and ASP.NET.

asyncbridge's Issues

I have a question!

I write a program follow your README.MD .I find it works fine and do not cause a deadlock. I am new to learn Async/await. Here is the code.

`

   class Program
{
    static void Main(string[] args)
    {

        var task = AsyncString();
        task.Wait();

        // This line will never be reached
        string res = task.Result;

        Console.WriteLine(res);


    }

    public static async Task<string> AsyncString()
    {
        await Task.Delay(1000);
        return "TestAsync";
    }
  }
   

    }

`

Any chance of getting a 4.0 version?

Is there any chance you could create a version that works with .Net 4.0 and the Microsoft.Bcl.Async libraries https://www.nuget.org/packages/Microsoft.Bcl.Async ?

I forked and did a test, after dropping the project back to targeting '.Net Framework 4.0 Client Profile' and installing the Microsoft.Bcl.Async package the only line of code that needed changing was line 155
from
Task.Run(() =>
to
TaskEx.Run(() =>

I'm happy to rename mine to AsyncBridge40 (or something similar) and publish to nuget, but it'd be nicer if the code could be shared and in the one place somehow.

I'm not a GitHub expert and I'm not a NuGet expert, so I'm not sure what's feasible and what isn't.
Let me know what you think,

cheers,
Scott

Early out of remaining tasks in child blocks when an exception is thrown.

Currently child events will continue running, they should be cancelled and dealt with in a safe manner.

Processing of UI blocked

When a task is awaited, the UI could repaint and trigger events. But this doesn't happen because _workItemsWaiting.WaitOne() also blocks the event queue of WPF windows. A DispatcherFrame can be pushed to continue the main dispatcher loop until this frame is canceled. That's how WPF synchronously waits for dialogs to return.

Should I propose a PR? I noticed this repo is somewhat stale.

It's available in net40 up and Windows desktop (WPF targets). So not on .net standard or Coree

Code that works for me:

private class ExclusiveSynchronizationContext : SynchronizationContext
{
    private bool _done;
    private EventQueue _items;
    private SynchronizationContext _old;
    private DispatcherFrame _dispatcherFrame;

    public Exception InnerException { get; set; }

    public ExclusiveSynchronizationContext(SynchronizationContext old)
    {
        _old = old;
        ExclusiveSynchronizationContext oldEx =
            old as ExclusiveSynchronizationContext;

        if (null != oldEx)
        {
            this._items = oldEx._items;
        }
        else
        {
            this._items = new EventQueue();
        }
    }

    public override void Send(SendOrPostCallback d, object state)
    {
        throw new NotSupportedException(
            "We cannot send to our same thread");
    }

    public override void Post(SendOrPostCallback d, object state)
    {
        _items.Enqueue(Tuple.Create(d, state));
        if (_dispatcherFrame != null)
        {
            _dispatcherFrame.Continue = false;
            _dispatcherFrame = null;
        }
    }

    public void EndMessageLoop()
    {
        Post(_ => _done = true, null);
    }

    public void BeginMessageLoop()
    {
        while (!_done)
        {
            EventTask task = null;

            if (!_items.TryDequeue(out task))
            {
                task = null;
            }

            if (task != null)
            {
                task.Item1(task.Item2);
                if (InnerException != null) // method threw an exeption
                {
                    throw new AggregateException(
                        "AsyncBridge.Run method threw an exception.",
                        InnerException);
                }
            }
            else
            {
                // No task to run, so we wait for the next post to cancel the dispatcher frame
                _dispatcherFrame = new DispatcherFrame();
                Dispatcher.PushFrame(_dispatcherFrame);
            }
        }
    }

    public override SynchronizationContext CreateCopy()
    {
        return this;
    }
}

Question about FireAndForget

Hi,

I stumbled upon your code, and found that I have a very similar way of doing a FireAndForget as you have in this library. Only, I don't have the body of the Task.Run delegate wrapped into another invokation. So like this:

    public static void FireAndForget(
        Func<Task> task,
        Action<Exception> handle = null)
    {
        Task.Run(async () =>
        {
            try
            {
                await task().ConfigureAwait(false);
            }
            catch (Exception e)
            {
                if (null != handle)
                {
                    handle(e);
                }
            }
        });
    }

I have the above code running fine in production, but am always looking to "harden" it anyways, so I was just wandering: why do you do that? What is the reason of that extra level of invokation?

Also: about the ConfigureAwait... I see that you don't use that. If my understanding about it is right, applying ConfigureAwait(false) means that the synchronisation context doesn't get captured for continuation, which is good here, as we don't need to continue anywhere anyway.

I read somewhere that in library or framework code (I guess this project falls under that category?), ConfigureAwait (false) should almost always be used, as it's more expensive to capture than not to capture, and if you don't need it anyway...

I could be terribly wrong though, as I'm still in the process of wrapping my brain around this whole async/await stuff... Please enlighten me if that's the case ;-)

Deadlock in MVC partial view render.

Hi,

Using Html.RenderAction in a razor view in combination of Async Brige in a controller method cause a deadlock.

I know MVC does not support async methods for partial view, that why I was hoping Async Bridge could help.

Thanks.

Add tests

The library is small, so we should have 100% code coverage, as well as testing all of the edge cases. Asynchronous coding with tasks has a lot of pitfalls, and we should be robust to them as well as documenting strange cases where it will not work as intended.

.Net Standard support.

Can you add .Net Standard and .Net Core support?