Chrome Version: ToT
OS: All

Socket pools generally don't cancel ConnectJobs when Requests are canceled, as per this code:
https://cs.chromium.org/chromium/src/net/socket/client_socket_pool_base.cc?rcl=b065d5b206ac5dcccbc853732b3ab3f7a841993b&l=581
This allows later Requests to adopt these orphaned ConnectJobs.  The potential inefficiency I see is that later Requests (that could adopt orphaned ConnectJobs) unconditionally create new ConnectJobs, even if plenty of orphaned ConnectJobs exist.  There's code to avoid creating new ConnectJobs for Requests if there are preconnect ConnectJobs:
https://cs.chromium.org/chromium/src/net/socket/client_socket_pool_base.cc?rcl=5dabc8d5b5cd48b1f6783142c327dd511f6ff117&l=386
But not orphaned non-preconnect ConnectJobs (because unassigned_job_count_ is only incremented "if (is_preconnect)", and not when Requests are cancelled and orphaned).

What steps will reproduce the problem?
(1) Request comes in and ConnectJob is created
(2) Request is canceled (ConnectJob is not canceled but orphaned)
(3) Another Request comes in and creates another ConnectJob even though the first one could be used and may complete sooner (because it was started sooner)

The upside to this inefficiency is that if prior ConnectJobs got stalled/stuck for some reason, perhaps the new ConnectJob might actually finish before the orphaned ones.

What is the expected result?
No need to create new ConnectJobs if orphaned ones exist.  Creating extra ConnectJobs can slow things down by using extra resources (memory, bandwidth).

What happens instead?
Extra ConnectJobs are created.

I discussed with mmenke@ briefly.  He noted:
It seems to me like we could get rid of |unassigned_job_count_| and instead just check if there are more pending connect jobs than pending requests, and if so, assign the current job.  One weirdness, though, is priorities.  If we have two low priority ConnectJobs and then a high priority request comes in, we would then keep the low priority requests...But this is exactly what we're doing with preconnects already, so we're clearly OK with that happening already.  I suppose if the initial connection requests all hang, it does mean trying to reload a page would just result on us endlessly getting stuck on the same hung connect request, though we can already get into that situation, anyways (With 6 preconnects all hanging), though it may be easier to get into that state, since now we'd just need one hanging connect job.