As described in its comment, #1601 did not fully fix the problems of #1600. It massively reduced the problem and the duration of the race condition, but did not remove it.
Opening many instances of the same com server in parallel can still cause exceptions in finish_writer. This is caused by two things:
Another python instance might have reached the os.rename between our os.unlink and our os.rename, causing our rename to fail. This could be fixed by simply replacing the os.rename with os.replace, but then:
Another python instance might currently be parsing the .py we want to override when we call os.replace, causing the replace to fail.
The only proper solution for this issue I could think of is to use a named mutex to force mutual exclusion between all the operations that might interfere with each other. This solution is implemented in this PR.
As described in its comment, #1601 did not fully fix the problems of #1600. It massively reduced the problem and the duration of the race condition, but did not remove it.
Opening many instances of the same com server in parallel can still cause exceptions in finish_writer. This is caused by two things:
os.rename
between ouros.unlink
and ouros.rename
, causing our rename to fail. This could be fixed by simply replacing theos.rename
withos.replace
, but then:os.replace
, causing the replace to fail.The only proper solution for this issue I could think of is to use a named mutex to force mutual exclusion between all the operations that might interfere with each other. This solution is implemented in this PR.