0232dc35cd
File locking interacts poorly with the path to replace a read only file handle with a read/write one. For performance reasons the old handle is not closed until the new one is put in place. With file locking this obviously cannot work because the first handle is holding a lock on the file. As a result, file_pool::open_file fails in this case. Even if we dropped the reference to the read only file handle before attempting to re-open it, the open could still fail if another thread is holding a reference to the read only handle. There doesn't seem to be a good way around this. The simple solution would be to always open files in read/write mode, but that has obvious safety downsides. Any other solution would significantly complicate the file pool code. Deprecating file locking seems to be the least bad option. |
||
|---|---|---|
| .. | ||
| src | ||
| Jamfile | ||
| Makefile.am | ||
| client.py | ||
| compile_cmd.in | ||
| compile_flags.in | ||
| link_flags.in | ||
| make_torrent.py | ||
| setup.py | ||
| simple_client.py | ||
| test.py | ||