I'm still on my memory-leak hunt and I noticed the following:
I have lots of live-instances of System.Threading.CancellationCallbackInfo-Objects coming from F#'s default-CancellationTokenSource (Async-Workflows).
The problem gets even worse if you declare a Source by yourself and use this inside a MailboxProcessor to span childs or tasks.
Seems like the GC cannot collect those spanned tasks/workflows because the CancellationTokenSource is holding references like this:
Most of those CancellationCallbackInfo-Objects gets to Gen2 - incredible as I just use local-references inside the MailboxProcessors-"loop" workflow ...
Is this a known issue and is there a solution/workaround?
For now I stoped using Cancellation-support and thread ManualResetEvents through the code for this ... not nice at all :(
If you are using StartChild
, there is a leak there (see also this), which will be fixed in the next release. You can work around it by using StartAsTask
.
It is a good practice to use your own CancellationTokenSource
to create a token, and explicitly pass the token to F# asyncs, so that you can Dispose
the CTS on your own terms.
(If you see a different leak that doesn't involve StartChild
, we'd love a small repro, so we can fix it!)