Why are client-level locks reused at the torrent level instead of using locks specific to torrents?

[Zerolzj]

Recently, while using the torrent reader to read data, I've frequently noticed that due to issues with lock contention, a significant amount of data isn't returned to me for half a minute or even several minutes. This has caused me considerable frustration. I discovered that the locks within the reader are client-level locks, which means that whenever any other torrent is added, the reader may become blocked for a long time. I tried replacing the locks in the reader with torrent-level locks, but found that this requires a substantial amount of work.

I have two questions：

1. Could you explain why this design decision was made initially?
2. Would adding torrent-level locks be a good approach in the end?

[anacrolix]

Do you have some profiles that show contention on the client level lock? You should be able to use the block profiler.

I've talked about the client level lock in a few other places. I have found that it's appropriate and faster than finer grained locking (although there are some other locks elsewhere in the code in a few places where it provided speed up) in this use case, however that could be changed if there is evidence of contention.