Multithreaded access to session and torrent_handles

[glassez]

This is not explicitly stated in the documentation, or I could not find it there (in that case, point your finger there for me, please). How is it supposed to access a session from multiple threads? Is it thread-safe, or should I use mutex-based locks? The same question applies to torrent_handles.

I can make some conclusions by looking at their source codes, but it would still be preferable to have some kind of statement from the libtorrent author to avoid misunderstanding. In addition, this is from the area that should be explicitly described instead of forcing application developers to dig into implementation details.

[glassez]

@arvidn It doesn't seem like it was such a difficult question for the creator of libtorrent that it wasn't answered casually. Or are you just not automatically subscribed to new Issues, so you didn't notice it?

[arvidn]

GitHub regularly does not notify me of new issues anymore, for some reason (it used to, but it's been years). It might be a cap to stay within a smaller number of emails.

The normal APIs on session and torrent_handle are all thread safe. They communicate with the main thread via a message queue. Other classes like torrent_info, create_torrent, bdecode_node, settings_pack do not have any internal locking but also no shared global state. They are safe to be used by specific threads (I.e. they behave like normal classes in the standard library).

I agree that this should be better documented.