[Qt-interest] Crash in QAbstractTableModel.beginRemoveRows

Stephen Kelly steveire at gmail.com
Sat Dec 11 17:44:53 CET 2010


Scott Aron Bloom wrote:
> 
> Is easily fixable with a properly placed QMutexLocker..

How so?

beginInsertRows will emit rowsAboutToBeInserted. Any observers (views or 
proxies) in different threads will connect to that signal with a 
QueuedConnection (AutoConnection is the default, which is QueuedConnection 
if the objects are in different threads). The situation is similar for the 
other protected methods/signals/slots.

beginInsertRows ( QModelIndex(), m_Index.lineCount(), m_Index.lineCount()); 

// Actually do the insert.

endInsertRows();

// We require that beginRemoveRows is not invoked until after all slots 
// connected to rowsInserted (which is emitted by endInsertRows)
// have completed.

beginRemoveRows ( QModelIndex(), 0, 0);

// Actually do the remove.

endRemoveRows();

How does a well placed mutex resolve that? The only thing I can think of 
that might work is processEvents(), but that just doesn't seem like a good 
idea. 

If you can show the mutex based solution, I'm interested.

> 
> 
> Clearly, not all "models" can be made threadsafe.. But many of them can.

Disagree! :)

Steve.

> 
> Scott





More information about the Qt-interest-old mailing list