Search Unity

Should Jobs be used for IO bound subroutines?

Discussion in 'Data Oriented Technology Stack' started by OswaldHurlem, Feb 22, 2018.

  1. OswaldHurlem

    OswaldHurlem

    Joined:
    Jan 6, 2017
    Posts:
    40
    I know the Burst compiler will not help me in these situations, but nonetheless there is some value in having the same interface for all activity off main thread.
    Checking IsCompleted is an un-abstracted way to handle async operations, but it's not necessarily a bad thing. In fact, Unity's AsyncOperation type lets you do something similar.
    If Jobs should not be used for IO bound subroutines, what does Unity recommend?
     
  2. james7132

    james7132

    Joined:
    Mar 6, 2015
    Posts:
    110
    If you are using the MonoBleedingEdge runtime, my general suggestion is to instead wrap AsyncOperations as Task<T>s and use async/await. These operations generally aren't being fired regularly (or at least shouldn't be), so even if it generates a bit of garbage, it isn't too costly a use. The language support makes it much more useful in these contexts, especially when multiple asynchronous operations need to be composed/chained in a more dynamic way than the current Jobs system allows, especially with regards to exception handling and cancelling ongoing tasks. Moreover, this would allow the main thread and those dedicated to Jobs to be open for actual work instead of polling for completion.

    A quick extension method to convert AsyncOperations to Task<T>s:
    Code (CSharp):
    1. public static Task<T> ToTask<T>(T operation) where T : AsyncOperation {
    2.   var completionSource = new TaskCompletionSource<T>();
    3.   operation.completed += (op) => completionSource.SetResult(operation);
    4.   return completionSource.Task;
    5. }
    This can then be used to chain together multiple loads, such as loading an asset bundle then loading an asset from it, or composed with other async operations.
     
    Last edited: Feb 22, 2018
  3. OswaldHurlem

    OswaldHurlem

    Joined:
    Jan 6, 2017
    Posts:
    40
    I have half a mind to use Task and other alternative control flow things like Rx, but I'd have to hear of a large-scale game successfully using them first. I'm cautious.
     
  4. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    2,355
    async/await isn't tied to threads. IO generally uses events not threads. So comparing async/await to jobs is apples and oranges.
     
  5. Necromantic

    Necromantic

    Joined:
    Feb 11, 2013
    Posts:
    115
    A convenient way to get callbacks / data back to the main thread when a job completes would be interesting.
    I'm not sure how restrictive Jobs are when it comes to the data types that are used in them but other than that I don't see why you couldn't use them.
    I don't think we have enough documentation/information on it to really make a definitive statement here.