4 ms·
>... larger than the codebase test suite I wonder if they directly test the concurrent use? It appears that the fix [1] of the OP bug did not lead to any addi
by zoomablemind 4y ago
>... larger than the codebase test suite
I wonder if they directly test the concurrent use?
It appears that the fix [1] of the OP bug did not lead to any addition/changes in resp. tests.
[1]:https://www.sqlite.org/src/info/15f0be8a640e7bfa https://www.sqlite.org/src/info/15f0be8a640e7bfa
P.S. looks like Fossil still has issues with content scrolling and wrapping to screen size (mobile).
- otoolep 4y agoActually, they added a unit test in a follow-on change: https://www.sqlite.org/src/info/dc7dd2d3e50e7cc4 https://www.sqlite.org/src/info/dc7dd2d3e50e7cc4
- zoomablemind 4y agoIndeed, thanks for pointing this one out. The test seems to test a shared access in rather a serial order. I wonder if underneath this is actually running as concurrent processes?
- otoolep 4y agoI may not be following your point, but I don't believe the root cause of this issue was a race condition, or anything that might be related to concurrency. The fundamental cause AFAIK was a SQLite connection was attempting to make a state transition (from one type of locking state to another) which shouldn't be allowed under certain circumstances, but the implementation didn't actually enforce this rule. So the added test really does test the root cause.