Download state are asynchronized in Tribler and libtorrent

[EinNarr]

I monitored such problem that several minutes after removing a torrent by calling session.remove_download(), libtorrent still regard this download as existing, returning a valid handle when requested. However, Tribler regards this download not existing, returning false when LaunchManyCore.download_exists() is called, returning None when torrent handle is queried.

This problem is estimated to be caused by the ineffectiveness of removing download functions. remove_download is a asynchronized function in libtorrent, while when in Tribler handle and other record is immediately removed without waiting for the deferred. However, why the download is still there in libtorrent after several minutes is still a myth to me.

[EinNarr]

Update: adding time.sleep(2) after calling session.remove_download() could prevent this problem.

[devos50]

@EinNarr note that adding a time.sleep on the reactor thread causes the whole reactor thread to stall and not continue with other tasks. In general, never use time.sleep in Twisted applications.

[EinNarr]

@devos50 I know that. And the sad news is that after running that for a whole day, I found the problem is still there. time.sleep() might have helped a bit, but it didn't solve the problem.

[arvidn]

there are some cases where deleting a torrent may legitimately take a very long time, but in normal circumstances is should not happen. For instance, on MacOS using the HFS+ filesystem, closing a file handle may take arbitrarily long. Since HFS+ doesn't support sparse files, closing the file will synchronise with the kernel zero-filling the gaps.

There may be hints of why the torrent is still around in the libtorrent alerts.

[devos50]

@arvidn thanks for that info, good to know!

[ichorid]

This problem should be fixed by Tribler-Libtorrent interface refactoring that is discussed in #3418. We cannot reliably fix this with our current code base. I will add it as a task there.
Please, if you want to make comments, do it in #3418.
Closing this one.