> What's the advantage of such a custom copy-on-write list? Any read operation is cheap and the iterator is not affected by concurrent modifications (unlike concurrent collections). Effectively what you get is a moment-in-time view of the collection, you don't have to add special conditions to track concurrent changes.
About using a queue, IMO we shouldn't rely on that sort of behaviour here (I think we discussed a similar queue approach for the pool in https://github.com/apache/tinkerpop/pull/903): - We should support concurrent writes to the connection, if we queue it and dequeue it, we might end up with an empty pool (at a certain time). We might need complicated logic to guard for that. - Using a enqueuing/dequeueing from a concurrent queue is not a cheap operation when multiple threads are accessing to it. We will be introducing unnecessary overhead. - We shouldn't iterate through all the connections when borrowing from the pool, we just need to round robin through them, sample pseudo code: ```C# // obtain something that is fixed for this small period of time IList<Connection> immutableCopyOfConnections = ... int counter = Interlocked.Increment(ref _sharedCounter); int index = counter % immutableCopyOfConnections.Count; return immutableCopyOfConnections[index]; ``` If we need to compare the one with least in-flight requests, we should minimize the amount of checks, for example check connections at `index` and `index+1`, instead of checking the whole list (`O(2)` vs `O(n)`). > Do you know whether the default `TaskScheduler` would work here? No, we will need a custom one like `LimitedConcurrencyLevelTaskScheduler`. [ Full content available at: https://github.com/apache/tinkerpop/pull/1077 ] This message was relayed via gitbox.apache.org for [email protected]
