Fix race condition between hasEntry and addObjectToCache

[Jimilian]

This commit removes inconsistency between checking hasEntry and creating new one. Now both actions are implemented with lock.

Fix for #179 (comment):

Traceback (most recent call last):
           File "clcache.py", line 1568, in <module>
           File "clcache.py", line 1447, in main
           File "clcache.py", line 1477, in processCompileRequest
           File "clcache.py", line 1547, in processDirect
           File "clcache.py", line 1530, in <lambda>
           File "clcache.py", line 1358, in postprocessHeaderChangedMiss
           File "clcache.py", line 1295, in addObjectToCache
           File "clcache.py", line 282, in setEntry
           File "clcache.py", line 777, in copyOrLink
         FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\\clcache\\objects\\4c\\4cdbbffca1bd7564d2756447347f0389\\object.tmp' -> 'C:\\clcache\\objects\\4c\\4cdbbffca1bd7564d2756447347f0389\\object'
         Failed to execute script clcache

[codecov-io]

Current coverage is 78.79% (diff: 100%)

Merging #204 into master will increase coverage by 0.21%

@@             master       #204   diff @@
==========================================
  Files             1          1          
  Lines           929        929          
  Methods           0          0          
  Messages          0          0          
  Branches        155        155          
==========================================
+ Hits            730        732     +2   
  Misses          166        166          
+ Partials         33         31     -2   

Powered by Codecov. Last update e25b61a...eab8e45

[webmaster128]

This destroys all concurrency since only one compile process can run a a time. The idea behind postProcessing is that we unlock the cache during the compile process.

The more interesting question I guess is: why would a buildsystem build the same object file multiple times in parallel, which is when happens in this stacktrace, as far as I can see.

[Jimilian]

Sorry, I thought that cache.lock is related only to one cache object. Not to entire cache.

Question is pretty good. I can imagine two reasons:

1. Two different objects have same hash. Chance is pretty small, but it exists. In this case this fix is not able to help.
2. Your PR - Handle missing and changed includes in direct mode #179 :)

So, if it breaks concurrency I will close this PR and just create for you.

[webmaster128]

2. Your PR - Handle missing and changed includes in direct mode #179 :)

Good idea, I'll try to check that. Let me know if that stacktrace happens in non-#179 setups as well.

I think you can close this in any case.