Why the manual garbage collection trigger in CefRuntime.Shutdown?

[Andreas Kolbow]

Hello!

I wonder why there are manual GC.Collect and GC.WaitForPendingFinalizers calls in CefRuntime.Shutdown. What are they needed for?
I ask this because I occasionally encountered deadlocks when calling CefRuntime.Shutdown and stumbled upon that code. After i removed those two lines I wasn't able to reproduce the deadlocks any more.
Now I am wondering what negative consequences that might have or if that was the right thing to do.

[Dmitry Azaraev]

Hello.

Full GC triggered manually before CefRuntime.Shutdown to free any existing managed wrappers (and as result - free native CEF objects). Generally before calling CefShutdown method any CEF objects should be deleted. It is true for browser itself, and for some other object types too. So this is solution for did not touch asserts / undefined behaviors on shutdown. You always will hit in asserts with CEF debug builds without GC.

Ignoring this can cause persistence-related problems, when browser should correctly flush caches / other disk-stored things.

Anyway deadlock while GC - it is abnormally, and should not be ignored.

1. (Real-life) If you do some magic on CEF threads - it is possible that thread becomes message thread with queued message (non UI). If i'm remember correctly this happens if you create XML serializer on CEF thread (and .NET implementation do lot of stupid stuff in this case, while calling c# compiler for create serializer). There is no easy way to detect this problem, but debugging may help. Have sense to digg in this direction anyway. As result -  rule one - avoid to do any unrelated tasks on CEF threads. In my case this is real-life example - and it has been very not intuitive because xml serializer has been static - but initialization happend on CEF thread instead of main thread. If you empty all thread queues then everything will be fine with GC. It is only one specific case, just for example.

2. Probably some task requires live UI message loop - in this case it is can be easily workarounded by rerunning standard message loop until GC did no finished. And you can do it before CefRuntime.Shutdown call. Or perform full GC when program exiting but message loop is still live. Very depends from your program shutdown process.

3. Debug/digg what really deadlocked.

4. May be have sense to update to new CEF. CefGlue update coming... soon.

--
You received this message because you are subscribed to the Google Groups "CefGlue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cefglue+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Kolbow]

Thanks for your answer!
We'll wait for the next Xilium-Version for now and will check it with the next version again.