Yes you are right, I realized the same thing just moments before.
Could you suggest any tips how to manage this without function overloading?
On Tue, 2 Jun 2020, 13:24 Yuval Lifshitz, <ylifshit@xxxxxxxxxx> wrote:
the problem with this solution is not the cost of searching the hash map, it is making this map thread safe.adding a lock would have a very bad impact on performance.On Tue, Jun 2, 2020 at 5:53 AM Abhinav Singh <singhabhinav0796@xxxxxxxxx> wrote:One way of doing this is to store vector of req_state in and unorderd_map<id,req _state>But searching through might cause some time latency, so to counter thisI will put a size limit of thousand so that when vector gets big it erases all its element along with unordered_map.this will ensure that cost of searching operation will be greatly reduced.Will this do?_______________________________________________On Mon, 1 Jun 2020, 21:34 Abhinav Singh, <singhabhinav0796@xxxxxxxxx> wrote:Hello everyone,My `req_state*` is containing spans for a particular request to trace that request, but as we know req_state is not available everywhere I tried to insert a req_state variable in CephContext class because every portion of RGW has access to it and so they will also have access to req_state, but this wont work because it is on time initialized and when request run in parallel race condition might occur and traces will be inaccurate.The Second method I tried was to include req_state in RGWRadosStore and RGWUserCtl because these are accessible to every function which I want to trace, but again these also have race condition risk.Can anyone give me any tip how to make req_state available in all functions(if not all then majority) particularly this functions like RGWRadosStore and RGWUserCtlThank You.
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
