Should remove synchronous block from LaunchSettingsProvider

[BillHiebert]

Using synchronous calls within async blocks can cause threadpool exhausting. Should investigate removing the ExecuteSynchronously call in the code below:

        private string _launchSettingsFileFolder;
        private string LaunchSettingsFileFolder
        {
            get
            {
                if (_launchSettingsFileFolder == null)
                {
                    _launchSettingsFileFolder = CommonProjectServices.ThreadingService.ExecuteSynchronously(async () => {
                        var props = await CommonProjectServices.ActiveConfiguredProjectProperties.GetAppDesignerPropertiesAsync().ConfigureAwait(true);
                        return await props.FolderName.GetValueAsync().ConfigureAwait(true) as string;
                    });

                    if (string.IsNullOrEmpty(_launchSettingsFileFolder))
                    {
                        _launchSettingsFileFolder = DefaultSettingsFileFolder;
                    }
                }
                return _launchSettingsFileFolder;
            }
        }

[BillHiebert]

Note. Should import the ISpecialFilesManager and use that to get the app designer folder.

[srivatsn]

We're unlikely to change this now and it's not causing any issues.

[davkean]

I'm debugging through Roslyn right now and I'm seeing signs that this is causing issues, I see 53 threads waiting just on this:

[davkean]

It looks like the majority of entry points into LaunchSettingsProvider are async, so we should just flow this through.

[lifengl]

Generally, we should prevent using JTF.Run other than implementing old contracts (especially old COM/UI thread contracts). Using it inside a thread pool thread may cause thread pool exhaustion issues, and froze the process for half second without CPU activities. Sometime, it takes two threads in JTF.Run to trigger this problem. We saw this issue in Dev 14, and tried to reduce them in CPS.

The reason is if you have code to block on thread pool and wait other async method to finish. Very often, the async method may require to run code in the thread pool to finish, so when the number of threads in this state reaches the number of thread pool threads, it will enter a virtual dead lock mode, until the thread pool manager to kick in and decide to add new threads to the pool. Thread pool manager only wakes up maybe every 250ms, we typically see it unblocked the pool after 500ms in dev 14. And we notice this type of issue randomly freezes IDE for short period of time, and very hard to reproduce.

[davkean]

Yeah I'm seeing random freezes - I wonder if this is related.

[lifengl]

If you track CPU usage, in the thread exhaustion scenario, you will see large gaps with no activity.

…

Sent from my phone On May 18, 2017, at 6:02 PM, David Kean <notifications@github.com<mailto:notifications@github.com>> wrote: Yeah I'm seeing random freezes - I wonder if this is related. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#1342 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ALGWwj8WlqjNBPxUdUlCEifE6E_4t0c5ks5r7OongaJpZM4LuLbH>.

[davkean]

Just ran into the same thing opening ProjectSystem.sln, just sitting there blocked on UI thread without zero CPU. I don't have a trace.

[davkean]

I have a proposed fix here: #2317. I'm yet to run this through the mill yet - I plan on doing this tomorrow.