Arvid Norberg
Arvid Norberg
look at these settings: http://libtorrent.org/reference-Settings.html#hashing_threads http://libtorrent.org/reference-Settings.html#checking_mem_usage
`hashing_threads` was un-deprecated in 1.2.8. That setting is not used in 1.1.14+, but it *is* used in 1.2.x
Are you creating a torrent, or checking it?
Do you know if you're limited by disk I/O or CPU to hash? If you're limited by disk I/O, make sure you only use a single read thread. you're also...
I don't have any plans, but I would be happy to support someone making bindings
I'm not aware of anyone working on this
please note that this affects ABI. There needs to be a new build option and a new inline namespace for using the new OpenSSL API.
I think you're right. There is most likely a data race there. However, I believe it's fixed by https://github.com/arvidn/libtorrent/pull/6923. With that patch the `torrent_info` object is no longer mutated, but...
the `torrent_handle` doesn't look at `torrent::m_info_hash` though. It looks at `torrent::m_torrent_file->info_hash()`. So the atomic operation happens in the call to `torrent::m_torrent_file.lock()` which returns a pointer to the (immutable) `torrent_info` object....
oops, you're right. I was reading `t` and thinking it was the `torrent_info` object