You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Memory leak is in the ContinueWith() section with the captured lambda parameter (despite the use of the wildcard) or the task being captured longer than it is needed.
When in use with a recursive async where it does a ValueTask/Task conversion, looks at the result and potentially recurses the action in the ContinueWith block appears effectively for the lifetime of the loop at times. This could be the life of the whole program as the Action may never return meaning the task's result is held in memory by this ContinueWith function. If the async is recursive and runs this over and over this could result in all task results remaining in memory. Switching to old fashioned Async.AwaitTask when awaiting the task in the async loop fixes the issue.
I think that the Infrastructures.asAsyncV function retains the object when memory profiling. Could be the wildcard arg, or the task object itself. I found this when profiling, tough leak to spot.
The text was updated successfully, but these errors were encountered:
@mvkara Thanks for the report, I have released FusionTasks as a final version. But now that I see it, I think I might be able to do something more, so I will try to think of more ways to implement this.
Memory leak is in the ContinueWith() section with the captured lambda parameter (despite the use of the wildcard) or the task being captured longer than it is needed.
When in use with a recursive async where it does a ValueTask/Task conversion, looks at the result and potentially recurses the action in the ContinueWith block appears effectively for the lifetime of the loop at times. This could be the life of the whole program as the Action may never return meaning the task's result is held in memory by this ContinueWith function. If the async is recursive and runs this over and over this could result in all task results remaining in memory. Switching to old fashioned Async.AwaitTask when awaiting the task in the async loop fixes the issue.
I think that the Infrastructures.asAsyncV function retains the object when memory profiling. Could be the wildcard arg, or the task object itself. I found this when profiling, tough leak to spot.
The text was updated successfully, but these errors were encountered: