Happy to have the internals of the Private::Then changed and add the required elements to the FOptions strucutre - but I couldn’t fulfill the functionality with this task system https://dev.epicgames.com/documentation/en\-us/unreal\-engine/tasks\-systems\-in\-unreal\-engine?application\_version\=5\.0 as it would block the thread it was waiting on until it completed. I’ve used the FTaskGraphInterface currently - but happy to change the task system under the hood to better align with the engine direction or even add more support for different types of async/multithreaded work.
I’ll make a JIRA to take the time to evaluate it properly.
Just a quick note though that we attach the utmost importance on performance and adding another layer over TaskGraph -> Scheduler is something that we not only need to evaluate on usability standpoint, but also on the performance side of things. Will this add additional cost over normal task graph task, additional allocations, etc… is something we’ll have to evaluate because once a solution start being used, its very hard to pull back and deprecate if people end up with performance problems. The other concerns is that we already have a future/promise implementation that we’d need to get rid of before accepting a new one, that alone is not going to be easy as there is already quite a lot of code using that old API.
Performance should absolutely be a concern and while I think it’s reasonable to have this layer - it’s defintely not as quick as not using it! And this stuff isn’t my day-to-day so I’m sure there’s time that somebody could squeeze out of it. I also completely understand the desire to deliver a clear and concise API for async work as well as future/promise concepts that represent the C++ standard behaviours.
I’d of course love it if it were accepted but this is mostly to close the loop on the conversation we had last year about the UE::Async::Tasks API.
Don’t hesitate to reach out if you’ve got any questions,
And this stuff isn’t my day-to-day so I’m sure there’s time that somebody could squeeze out of it. I also completely understand the desire to deliver a clear and concise API for async work as well as future/promise concepts that represent the C++ standard behaviours.