+ for {
+ var avail int64
+ avail, err = r.waitAvailable(ctx, pos, int64(len(b)), n == 0)
+ if avail == 0 {
+ return
+ }
+ firstPieceIndex := pieceIndex(r.torrentOffset(pos) / r.t.info.PieceLength)
+ firstPieceOffset := r.torrentOffset(pos) % r.t.info.PieceLength
+ b1 := missinggo.LimitLen(b, avail)
+ n, err = r.t.readAt(b1, r.torrentOffset(pos))
+ if n != 0 {
+ err = nil
+ return
+ }
+ if r.t.closed.IsSet() {
+ err = fmt.Errorf("reading from closed torrent: %w", err)
+ return
+ }
+ r.t.cl.lock()
+ // I think there's a panic here caused by the Client being closed before obtaining this
+ // lock. TestDropTorrentWithMmapStorageWhileHashing seems to tickle occasionally in CI.
+ func() {
+ // Just add exceptions already.
+ defer r.t.cl.unlock()
+ if r.t.closed.IsSet() {
+ // Can't update because Torrent's piece order is removed from Client.
+ return
+ }
+ // TODO: Just reset pieces in the readahead window. This might help
+ // prevent thrashing with small caches and file and piece priorities.
+ r.log(log.Fstr("error reading torrent %s piece %d offset %d, %d bytes: %v",
+ r.t.infoHash.HexString(), firstPieceIndex, firstPieceOffset, len(b1), err))
+ if !r.t.updatePieceCompletion(firstPieceIndex) {
+ r.log(log.Fstr("piece %d completion unchanged", firstPieceIndex))
+ }
+ // Update the rest of the piece completions in the readahead window, without alerting to
+ // changes (since only the first piece, the one above, could have generated the read error
+ // we're currently handling).
+ if r.pieces.begin != firstPieceIndex {
+ panic(fmt.Sprint(r.pieces.begin, firstPieceIndex))
+ }
+ for index := r.pieces.begin + 1; index < r.pieces.end; index++ {
+ r.t.updatePieceCompletion(index)
+ }
+ }()