This disables background file closing when in not in main thread
Details
- Reviewers
indygreg krbullock - Group Reviewers
hg-reviewers - Commits
- rHG60f2a215faa7: workers: don't use backgroundfilecloser in threads
Ran pull, update, sparse commands and watched the closer threads created and destroyed in procexp.exe
ran test on CentOS. No tests broken compared to the base
Diff Detail
- Repository
- rHG Mercurial
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
The main reason we have this restriction is because there is an upper limit to the number of open file descriptors a process can have. So if we have multiple instances and each is managing file closes for thousands of files, we could easily exhaust all available file descriptors. This would lead to random I/O failures (likely when trying to open a file), which would likely raise an uncaught exception and lead to an abort.
So if we want to use multiple threads for workers on Windows, I think a better course of action is to reuse the singleton background file closer from all threads or not use a background file closer at all.
That sounds good. I actually started with a change to manage a single background closer between threads, but the locking code gets a bit complicated and seemed more risky. I didn't know the main reason for 1 background closer was the number of descriptors.
I'll check what disabling backgroundcloser does to the performance.
mercurial/vfs.py | ||
---|---|---|
420–421 | nit: wrap lines using () instead of \, eg if (backgroundclose and isinstance(...)): |
nit: wrap lines using () instead of \, eg
if (backgroundclose and