Since i/o operations are not synchronized, it is possible that one thread closes file handle, opened in another thread. With addition of `hidden` file attribute, an old bug in `part_file::open_file()` revealed both problems, causing a lot of random i/o errors in parts file. Fixing `open_file` bug should reduce the number of such errors back to 'normal'.
C++ standard and Boost requirements are connected:
1. With C++11 onward, we require Boost system component, with
C++03 we need chrono and random components too
2. When building against boost 1.66 and newer, C++11 is required.
Closes#3011, partially closes#2966.
Move the transition to downloading after the torrent has been checked
for being finished. This prevents a spurious state_changed_alert when
adding a torrent which is already completed.
Also move the posting of the torrent_checked_alert to maintain the
historical ordering of that alert with respect to the transition out of
checking_resume_data.
This alert's priority must be higher than `block_downloading_alert`'s
to allow custom handling of file errors.
With progress notifications enabled, network thread might fully load
alerts queue, so file errors from disk thread won't have a chance to
be delivered.
Don't allow peer connection to ask quota from bandwidth manager if send buffer is empty.
Remove undefined member function
Update download rate multiplier
Most status alerts should have priorities above normal level. Good reason for this is resume data verification case. For a large torrent(having lots of pieces) whole alert queue will be overflowed
with a `piece_finished_alert` right after resume data has been verified. Thus alerts like `torrent_checked_alert`, `torrent_finished`, `state_changed_alert` will not go the alerts queue.
* Introduce alert_priority enumeration
* Bump state_changed_alert's priority
* Set dht_direct_response_alert priority to `critical`
Calling blocks_flushed can cause the piece entry to be freed so its
callers need to be aware of that and avoid dereferencing the pointer if
the entry is freed.
If `default_storage::has_any_file` fails during fastresume data check, `piece_manager::check_no_fastresume` will skip storage initialization. In such case, any storage operation that require part file will cause an application crash.
Versions of boost as recent as 1.63 do not create a stub alias for python3
which causes build failures if no version of python3 is configured.
Duplicate that behavior so that building works even on older versions of
boost.
arvidn