settings-view forks too many instances of apm when using Update All to update packages

[BinaryMuse]

We should queue these up

[lee-dohm]

See also: #746, #546, and #519

[BinaryMuse]

@lee-dohm Apologies; it's probably obvious but I didn't search for this before rushing out the door. :) I'll leave it to you which of these should be de-duped; for what it's worth I looked into this a bit and there is an apm process forked for each update, whether or not one uses Update All or clicks Update one at a time on multiple packages. I would like to have a global installation/update queue for packages; I could change this issue to suggest a more detailed solution if you'd like.

[lee-dohm]

I definitely think we should put a cap on this to prevent contention, like max 1 package updating per core. But I also agree with Raymond Chen regarding not worrying about using 100% CPU.

[lee-dohm]

@BinaryMuse Don't worry about it 😀 I'm glad someone is motivated to work on it. I just wanted you to have the full context.

[Arcanemagus]

I definitely think we should put a cap on this to prevent contention, like max 1 package updating per core.

Note that I/O is more likely to be the limiting factor here instead of CPU.

[FalkF]

@BinaryMuse
I would like to implement an update queue, what should it look like?
Do we need a setting for max simultaneously running apm instances?
If so, where should it go: core settings or update panel?
And what should be the default: 1 or X or core count (bad choice I guess) or dependent on network andOr diskspeed?

There is also the possibility of passing more than one package to apm.
This opens up the possibility of running one instance for all updates or split the updates onto X processes.
But I would prefer a queue, because this would make cancellation #937 easier.