Single CGC computation + locking on read #20
Conversation
* Updating the locking * Update caching.jl * Update caching.jl Removed some debug options and cleaned some code * Update caching.jl
Codecov ReportAttention: Patch coverage is
|
|
This looks great! I am also pretty sure the pidlock on read is not doing a whole lot, but in principle the scratchspace is shared per user, so if you would start up two sessions of Julia at the same time, it might still mess up? Honestly, I'd rather err on the cautious side with these things. |
|
Thanks for the help. |
|
I also saw this, I am not sure if this is just the interplay with CI or an actual problem. Should I hold off on tagging, such that you can try it out for a while longer before I release this version? |
|
Maybe let's wait the night.
…On Wed, 31 Jul 2024, 17:39 Lukas, ***@***.***> wrote:
I also saw this, I am not sure if this is just the interplay with CI or an
actual problem. Should I hold off on tagging, such that you can try it out
for a while longer before I release this version?
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXMRNR55UQAEHNNA6SJPHXTZPEAL5AVCNFSM6AAAAABLYCVF32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRQHAYTOOJUGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
As discussed with @lkdvos
Instead of computing the CGCs of all s3 when encountering s1 x s2 => s3, we just compute the CGCs of the relevant s3.
Following discussion, I added a lock on reading the CGC file. I am relatively convinced it is not useful.
Finally, I slightly modified the dist_cache_info function so it does not crash if some pid file are still there, or if some files are corrupted. Instead it simply reports them. I added an option to clean these files. I did not test it enough (due to ownership shenanigans).