More complex locking in StackTrace::toString#62332
Conversation
|
This is an automated comment for commit f7fdb2c with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page
Successful checks
|
|
Why cannot we change the lock type to SharedMutex? First lock shared and try to just read from cache. If it fails: unlock shared, lock exclusive, check again if it is in cache. If hit - return from cache, if not - run If it is the second, then maybe the cache is wrong? Because it should be relatively small IMO, but it grows indefinitely. |
I saw some clusters being stuck on the cache lock, which could be explained with some deadlock/error in fetching string lines or by really slow execution of Simpler solution would be to unlock the cache while creating string, but I added cv to try avoiding doing same work twice. This was just an idea I quickly implemented to see opinions, so I can easily close this if it doesn't make sense to you. |
Changelog category (leave one):
Documentation entry for user-facing changes
Modify your CI run:
NOTE: If your merge the PR with modified CI you MUST KNOW what you are doing
NOTE: Checked options will be applied if set before CI RunConfig/PrepareRunConfig step
Include tests (required builds will be added automatically):
Exclude tests:
Extra options:
Only specified batches in multi-batch jobs: