Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to change the DefaultMaxDegreeOfParallelism value programmatically #3539

Open
mrward opened this issue Sep 28, 2016 · 3 comments
Labels
Platform:Mono NuGet.exe on mono scenarios Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Status:Excluded from icebox cleanup Status:Inactive Icebox issues not updated for a specific long time Triage:Investigate
Milestone

Comments

@mrward
Copy link
Member

mrward commented Sep 28, 2016

Can we provide a way to change the DefaultMaxDegreeOfParallelism used in various places in NuGet?

Having a large default value of 16 causes problems with restore in Xamarin Studio on Mono.

In the InstallCommand parallel processing is disabled on Mono:

https://github.com/NuGet/NuGet.Client/blob/250b20d83f57c687665f8682d80ef76efaaf5a00/src/NuGet.Clients/NuGet.CommandLine/Commands/InstallCommand.cs#L59

In other places this does not seem to be not possible since the DefaultMaxDegreeOfParallelism value is used directly.

To get around this problem in Mono I ended up changing the DefaultMaxDegreeOfParallelism constant to 1 and built NuGet from source. However it would be better if this could be modified or parallel processing disabled programmatically whilst this problem exists with Mono.

@mrward mrward added the Platform:Mono NuGet.exe on mono scenarios label Sep 28, 2016
@rrelyea rrelyea added this to the 4.0 RC3 milestone Dec 9, 2016
@rrelyea
Copy link
Contributor

rrelyea commented Dec 9, 2016

@zhili1208 - please investigate solution for this problem

@rrelyea rrelyea modified the milestones: Future-1, 4.0 RC3 Jan 3, 2017
@rrelyea
Copy link
Contributor

rrelyea commented Jan 3, 2017

@mrward - We weren't able to do this in 4.0. If still important, we'll consider in future.

@mrward
Copy link
Member Author

mrward commented Jan 4, 2017

Xamarin Studio has increased the number of thread pool threads available to it which seems to prevent the hang I was seeing before. However there does seem to be a problem restoring a lot of NuGet packages with Mono 4.8 and Xamarin Studio 6.2 which uses unpatched NuGet 3.5. Some of the socket connections seem to time out which I suspect is due to Xamarin Studio running out of thread pool threads during the restore. Running the restore again works presumably since only a few NuGet packages are being restored the second time.

Xamarin Studio 6.1 with a patched version of NuGet 3.4, which has DefaultMaxDegreeOfParallelism set to 1, and restoring a lot of NuGet packages works first time.

@jainaashish jainaashish modified the milestones: Future-1, Backlog Oct 17, 2017
@jainaashish jainaashish added the Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. label Oct 17, 2017
@ghost ghost added the Status:Inactive Icebox issues not updated for a specific long time label Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform:Mono NuGet.exe on mono scenarios Priority:3 Issues under consideration. With enough upvotes, will be reconsidered to be added to the backlog. Status:Excluded from icebox cleanup Status:Inactive Icebox issues not updated for a specific long time Triage:Investigate
Projects
None yet
Development

No branches or pull requests

7 participants