WIP Threadsafe connection pooling

[andrewvc]

WORK IN PROGRESS. DO NOT MERGE.

[karmi]

The more I think about it, Andrew, the more I think it would be more beneficial to go with the Mutex.synchronize approach for the first pass on this refactoring, and identify the “map” of problematic spots, as I have mentioned on the call. From there, we can dive into a deeper re-structuralization of the whole architecture.

As always, please ping me if you need assistance, feedback or just an opinion.

[jsvd]

@karmi by Mutex.synchronize, you mean a global mutex on perform_request and reload_connections!. Well, not exactly since the first calls the second, but is that the idea?

[karmi]

@jsvd, not in this way specifically — it was more or less a suggestion for Andrew to continue with adding the mutexed locks around problematic spots (which he already did in other places).

[andrewvc]

@jsvd this was in reference to the last conversation @karmi and I had where we discussed using synchronize vs. threadsafe datastructures from concurrent-ruby.

In my opinion (since you're taking over this @jsvd) we should just use the appropriate tool for the job and discuss the design once we're done.

[ArnonHongklay]

endline ?

[andrewvc]

Moved to #296