pool: fix idle_conns assertion in test_pool_close

[kimshrier]

I noticed that test_pool_close() would sometimes fail, but not all the time. On line 224, sometimes there would be 5 entries in idle_conns and sometimes 6. After reviewing the code in vlib/pool/connection.v, if prune_connections() runs between the calls to c := p.get() and p.put(c), which can happen, then an additional conn will get allocated because the number of idle conns has dropped below the min_idle_conns value of 5.

I printed out some intermediate values in the test and captured the following when the test failed.

    mut p := pool.new_connection_pool(factory, pool.ConnectionPoolConfig{})!

immediately after this statement, I extracted the following values:

all_conns:
             id: 01982311-32dc-783d-bd03-bd9529cb9dca usage_count: 0  addr: 0x827b0e880
             id: 01982311-32dc-76df-aac7-538e8d6c160f usage_count: 0  addr: 0x827b0e850
             id: 01982311-32dc-7c47-8f74-1b01d564eef4 usage_count: 0  addr: 0x827b0e830
             id: 01982311-32dc-7e29-94f4-8360315f8a1f usage_count: 0  addr: 0x827b0e810
             id: 01982311-32dc-790e-a478-b6d76913f107 usage_count: 0  addr: 0x827b0e7f0

idle_pool:
             id: 01982311-32dc-783d-bd03-bd9529cb9dca usage_count: 0
             id: 01982311-32dc-76df-aac7-538e8d6c160f usage_count: 0
             id: 01982311-32dc-7c47-8f74-1b01d564eef4 usage_count: 0
             id: 01982311-32dc-7e29-94f4-8360315f8a1f usage_count: 0
             id: 01982311-32dc-790e-a478-b6d76913f107 usage_count: 0

After the next 2 statements execute:

    c := p.get()!
    p.put(c)!

I extracted out the following values:

all_conns:
             id: 01982311-32dc-783d-bd03-bd9529cb9dca usage_count: 0  addr: 0x827b0e880
             id: 01982311-32dc-76df-aac7-538e8d6c160f usage_count: 0  addr: 0x827b0e850
             id: 01982311-32dc-7c47-8f74-1b01d564eef4 usage_count: 0  addr: 0x827b0e830
             id: 01982311-32dc-7e29-94f4-8360315f8a1f usage_count: 0  addr: 0x827b0e810
             id: 01982311-32dc-790e-a478-b6d76913f107 usage_count: 1  addr: 0x827b0e7f0
             id: 01982311-32fb-721b-a203-345b3d71a116 usage_count: 0  addr: 0x82c383fe0

idle_pool:
             id: 01982311-32dc-783d-bd03-bd9529cb9dca usage_count: 0
             id: 01982311-32dc-76df-aac7-538e8d6c160f usage_count: 0
             id: 01982311-32dc-7c47-8f74-1b01d564eef4 usage_count: 0
             id: 01982311-32dc-7e29-94f4-8360315f8a1f usage_count: 0
             id: 01982311-32fb-721b-a203-345b3d71a116 usage_count: 0
             id: 01982311-32dc-790e-a478-b6d76913f107 usage_count: 1

This tells me that after the call to get a connection from the pool, and before the call to put the connection back in, prune_connections() ran in the background. We can see that the last idle connection was returned by get() and its usage count was incremented. Then another connection was allocated to bring the number of idle connections back up to 5. Finally, the connection returned by get() was put back into the pool.

So, it looks to me that the proper assertion should be >= instead of ==.

[huly-for-github]

Connected to Huly®: V_0.6-23401

[spytheman]

Excellent analysis.
Thank you 🙇🏻‍♂️ .