🤖 Bump the ArgTools stdlib from fa87869 to 641aa3f

[DilumAluthgeBot]

Stdlib: ArgTools
Branch: master
Old commit: fa87869
New commit: 641aa3f
Bump invoked by: @StefanKarpinski

$ git log --oneline fa87869..641aa3f
641aa3f no lock: pass lock=false to file open calls (#23)
1ff44c8 Merge pull request #22 from DilumAluthge/dpa/gha-windows
6c1199b Run CI on Windows
21a396d Merge pull request #21 from DilumAluthge/dpa/github-actions-ci
064c813 Add GitHub Actions CI and remove Travis CI
b83f736 README.md: fix typos (#17)

[vtjnash]

no lock: pass lock=false to file open calls

Wait, this sounds like a bad idea from the title

[StefanKarpinski]

It is documented and last I was aware doing locking was a major performance issue.

[StefanKarpinski]

@vtjnash: I'm going to merge this unless I get a clear statement to the effect that locking is no longer a performance issue for I/O.

[ChrisRackauckas]

aaronang/stl-benchmark#3 is an example of a benchmark that gets hit by the lock performance issue.

[KristofferC]

It does seem non-ideal to me that open is thread-safe by default but that a standard library function (which is a small wrapper around open) changes that default to be unsafe. At least it should have the same kwarg option as open with the same default and propagate that to the inner open call?

[vtjnash]

propagating any ; kwargs... seems sensible