WIP: add callbacks to alerts (should I continue?)

[joriscarrier]

this pull request allows you to have a callback (which will be executed on the libtorrent thread when the alert is set in the queue) on asynchronous methods that trigger alerts:

torrent_handle:

• add_piece
• read_piece
• post_peer_info
• post_status
• post_download_queue
• post_trackers
• set_metadata
• flush_cache
• force_recheck
• save_resume_data
• post_piece_availability
• prioritize_files
• file_priority
• scrape_tracker
• move_storage
• rename_file

session_handle:

• post_torrent_updates
• post_session_stats
• post_dht_stats
• async_add_torrent
• dht_live_nodes
• dht_sample_infohashes
• dht_direct_request
• remove_torrent

[joriscarrier]

a simple example:

std::mutex m;
std::condition_variable cv;

bool done = false;
th.flush_cache([&cv, &done] (const lt::cache_flushed_alert* alert) {
    // here you are in the libtorrent network thread
    done = true;
    cv.notify_one();
});

{
    std::unique_lock lk(m);
    while (!done) cv.wait(lk);
}

[glassez]

For me, it doesn't look too useful to use callbacks to get some requested data from libtorrent, which will simply be used in another thread (existing alerts will also be quite suitable here).
For me, it looks much more useful to be able to set callbacks for some events that occurred during the torrenting process (in general, not initiated from the user side, for example, when metadata is received, torrent finished etc.), so that you can make some immediate impact on libtorrent itself, which can be too late to do during regular alert processing in the application thread. And (I don't remember if I mentioned this earlier in another discussion), it shouldn't be tied to alerts. It just has to be some key events (on_metadata_received, on_torrent_finished or more generic on_torrent_state_changed, etc.) that can also generate alerts or may not do so. In any case, this should be regardless of the current alert subscription.

[joriscarrier]

For me, it looks much more useful to be able to set callbacks for some events that occurred during the torrenting process (in general, not initiated from the user side, for example, when metadata is received, torrent finished etc.), so that you can make some immediate impact on libtorrent itself

looks like you want to use a torrent_plugin ?

my proposal is based on the fact that without a similar modification on the client side (at the level of torrent_handle or session_handle) you cannot identify which alerts correspond to which calls.

[glassez]

looks like you want to use a torrent_plugin ?

I have to use libtorrent extensions feature (torrent_plugin etc.) currently to workaround it.
I just want it to be more powerful and convenient.

[glassez]

my proposal is based on the fact that without a similar modification on the client side (at the level of torrent_handle or session_handle) you cannot identify which alerts correspond to which calls.

Agree. It makes sense in case when some alert is reaction to user requested action.

[joriscarrier]

looks like you want to use a torrent_plugin ?

I have to use libtorrent extensions feature (torrent_plugin etc.) currently to workaround it. I just want it to be more powerful and convenient.

like a torrent_handle::wait(std::function<void(lt::torrent_status)>) feature ??

[glassez]

like a torrent_handle::wait(std::function<void(lt::torrent_status)>) feature ??

Something like void session_handle::on_torrent_state_changed(std::function<void (torrent_handle, torrent_status::state_t)>); (where second parameter of callback is previous state)

[e1y4s]

That would be a super interesting feature to simplify the coding workflow by writing logic "where you need it and where you understand the need" (and without having to create a new extension)