[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