f519cfaa63
The original intent of making thread_release() wait for other requesters to proceed was more of a fairness trade, guaranteeing that a thread that was granted an access to the CPU would be in turn giving back once its job is done. But this is counter-productive as it forces such threads to spin instead of going back to the poller, and it prevents us from implementing multiple levels of guarantees, as a thread_release() call could spin waiting for another requester to pass while that requester expects stronger guarantees than the current thread may be able to offer. Let's just remove that wait period and let the thread go back to the poller, a-la "race to idle". While in theory it could possibly slightly increase the perceived latency of concurrent slow operations like "show fd" or "show sess", it is not the case at all in tests, probably because the time needed to reach the poller remains extremely low anyway.
The HAProxy documentation has been split into a number of different files for ease of use. Please refer to the following files depending on what you're looking for : - INSTALL for instructions on how to build and install HAProxy - BRANCHES to understand the project's life cycle and what version to use - LICENSE for the project's license - CONTRIBUTING for the process to follow to submit contributions The more detailed documentation is located into the doc/ directory : - doc/intro.txt for a quick introduction on HAProxy - doc/configuration.txt for the configuration's reference manual - doc/lua.txt for the Lua's reference manual - doc/SPOE.txt for how to use the SPOE engine - doc/network-namespaces.txt for how to use network namespaces under Linux - doc/management.txt for the management guide - doc/regression-testing.txt for how to use the regression testing suite - doc/peers.txt for the peers protocol reference - doc/coding-style.txt for how to adopt HAProxy's coding style - doc/internals for developer-specific documentation (not all up to date)