I am skimming through my code and noticed a circumstance where I'm not sure whether it is potentially dangerous.

I have a QTableView to visualize a download queue. It uses a custom QAbstractTableModel subclass (using pyqt5 here) :
Qt Code:
  1. class DownloadQueueTableModel(QAbstractTableModel):
  2.  
  3. downloadQueue = deque()
  4. queueLock = Lock()
  5.  
  6. def addToQueue(self, item):
  7.  
  8. row = self.queueLength()
  9. self.beginInsertRows(QModelIndex(), row, row)
  10.  
  11. with self.queueLock:
  12. self.downloadQueue.append(item)
  13.  
  14. self.endInsertRows()
  15.  
  16. def getNextItem(self):
  17. if self.queueLength() == 0:
  18. return None
  19. self.beginRemoveRows(QModelIndex(), 0, 0)
  20. with self.queueLock:
  21. item = self.downloadQueue.popleft()
  22. self.endRemoveRows()
  23. return item
To copy to clipboard, switch view to plain text mode 

My table model uses an internal queue to save the data. While the addToQueue method is called as a reaction to a button click - and therefore in the context of the UI thread - the getNextItem method is called from a worker thread, which downloads the items one after the other.
The access to the queue data structure itself is protected through a lock and therefore thread safe, the only question that remains:
Is a call to beginRemoveRows and endRemoveRows from another thread, which is not the UI thread, safe?

The application is running correctly and I have not noticed any problems so far, but we all now that errors caused by racing conditions are very random and hard to find later on.