2013-09-03 6 views
5

Powiedzmy, że miałem obliczenia F # do radzenia sobie w C# i chciałem, aby były one uruchamiane synchronicznie. Jaki byłby różnicy pod maską między:Async.RunSynchronously() vs Async.StartAsTask(). Wynik

public static T RunSync<T>(FSharpAsync<T> computation) 
    { 
     return FSharpAsync.RunSynchronously(computation, 
      timeout: FSharpOption<int>.None, 
      cancellationToken: FSharpOption<System.Threading.CancellationToken>.None 
      ); 
    } 

lub

public static T RunSync<T>(FSharpAsync<T> computation) 
    { 
     return FSharpAsync.StartAsTask(computation, 
      taskCreationOptions: FSharpOption<TaskCreationOptions>.None, 
      cancellationToken: FSharpOption<System.Threading.CancellationToken>.None 
      ).Result; 
    } 

Przepraszam, jeśli wydaje się to proste pytanie, jestem całkiem nowy w programowaniu asynchronicznym!

Odpowiedz

8

Myślę będą zasadniczo takie same - jak mówi Reed, pierwsza kolejek pracę bezpośrednio, podczas gdy druga tworzy Task, ale stworzony Task jest dość lekki przedmiot (pod osłoną, to jest prawie taka sama i zadanie jest tworzone przy użyciu TaskCompletionSource - można see the code here).

Jeśli masz kontrolę nad biblioteką F #, to moim zaleceniem byłoby tylko ujawnienie metody, która zwraca Task i ukrycie Fyn async - to sprawi, że użycie z C# będzie dużo wygodniejsze i unikniesz wszystkich specjalnych Typy F (jak opcje). Jeśli masz someWork funkcję w F #, a następnie chciałbym napisać:

type NiceCSharp = 
    static member SomeWork() = 
    Async.StartAsTask(someWork()) 
    static member SomeWork(cancellationToken) = 
    Async.StartAsTask(someWork(), cancellationToken = cancellationToken) 

Po stronie C#, widać piękny przeciążone metody, która zwraca Task i dobrze współpracuje z await. Oczywiście, możesz po prostu oczekiwać wyniku synchronicznie za pomocą Result, ale narzut nie jest zbyt duży - a fakt, że wystawiasz ładny interfejs API C#, ułatwi integrację F # w twoim systemie.