Pergunta

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: enter image description here

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 :(

Foi útil?

Solução

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!)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top