BeginResetModel() not working
-
I think you're misusing beginResetModel/endResetModel.
- beginResetModel/endResetModel will simply cause the emission of the model's modelAboutToBeReset / modelReset signals, update bookeeping information (persistent indexes), etc.
- views are allowed to ask for data() at any time, therefore returning to the event loop with the model in a "inconsistent" state is wrong
In your testcase you're simply adding rows/columns with a progress, and therefore you should actually be using beginInsertRows / beginInsertColumns; or, complete the model reset in each iteration, before returning to the event loop.
-
[quote author="deisik" date="1348647304"][quote author="Andre" date="1348644977"]My guestimate is that it will block signals from the model to the view, so you are free to mess with internal data structures without triggering any premature updates to the view[/quote]
There are no signals from the model which are not explicitly specified in the code of the model. What sense does it make to specify signals in the data rebuild routine?[/quote]
I'm not sure I understand exactly what you mean here, but like I said: if you really want to know what it does: the source is there for you to inspect. Like I said: I was only guessing.
[quote]
[quote author="Andre" date="1348644977"]However, it will not inform the view by itself. That means that if you return to the eventloop, things like a paintevent in the view may still result in data queries[/quote]This contradicts to what Stephen wrote. If event loops are explicitly prohibited (by definition as he says, not because they can't be used) within beginResetModel/endResetModel then there is no sense in beginResetModel/endResetModel as such because these methods do nothing to impose this prohibition[/quote]
[/quote]
No, I don't think it contradicts, but if it does: trust Stephen on this, not me.You should keep in mind that any signal that you trigger results in a direct method call, unless the connection is of queued type. That normally only is the case for signal-slot connections between threads. So no, you do not need an eventloop for signal-slot connections to work. Anything you do during your reset may trigger signals that I suspect will be blocked by the beginResetModel. However, note that there is a modelAboutToBeReset() signal, so that will be emitted for sure.
-
[quote author="peppe" date="1348647631"]
- beginResetModel/endResetModel will simply cause the emission of the model's modelAboutToBeReset / modelReset signals, update bookeeping information (persistent indexes), etc.
- views are allowed to ask for data() at any time, therefore returning to the event loop with the model in a "inconsistent" state is wrong[/quote]
Your first proposition contradics the second one. Views being allowed to ask for data at any time means that model should always be in a consistent state. And what about resetting model in this case?
-
[quote author="Andre" date="1348647770"]Anything you do during your reset may trigger signals that I suspect will be blocked by the beginResetModel. However, note that there is a modelAboutToBeReset() signal, so that will be emitted for sure.[/quote]
No, they don't get blocked as you can see in the test case
-
[quote author="deisik" date="1348648089"][quote author="peppe" date="1348647631"]
- beginResetModel/endResetModel will simply cause the emission of the model's modelAboutToBeReset / modelReset signals, update bookeeping information (persistent indexes), etc.
- views are allowed to ask for data() at any time, therefore returning to the event loop with the model in a "inconsistent" state is wrong[/quote]
Your first proposition contradics the second one. Views being allowed to ask for data at any time means that model should always be in a consistent state. And what about resetting model in this case?
[/quote]
No, it is not a contradiction. It means that models always need to be in a consistent state at the moment that they:- return to the eventloop, or
- emit signals (that also yields control and may trigger a view asking for data, directly or indirectly)
So: don't do the above during your reset. As long as you don't, the view's can't request data, as the current point in your code is in your model reset procedure, not in a view querying your model. Unless you are using multiple threads, which is not supported between a model and a view.
Edit:
[quote author="deisik" date="1348648438"][quote author="Andre" date="1348647770"]Anything you do during your reset may trigger signals that I suspect will be blocked by the beginResetModel. However, note that there is a modelAboutToBeReset() signal, so that will be emitted for sure.[/quote]
No, they don't get blocked as you can see in the test case
[/quote]
No, you are right. If you look at the source code, all it does (in 4.8.1) is:
@void QAbstractItemModel::beginResetModel()
{
emit modelAboutToBeReset();
}
@So, no signal blocking. My guestimate was wrong.
-
[quote author="Andre" date="1348648503"]No, it is not a contradiction. It means that models always need to be in a consistent state at the moment that they:
- return to the eventloop, or
- emit signals (that also yields control and may trigger a view asking for data, directly or indirectly)[/quote]
This basically means that beginResetModel/endResetModel are meaningless/useless because they don't block return to the eventloop, which occurs if you (me) try to run a progress bar for data reset process. They just do nothing, if you don't return to eventloop, views in no case by themselves will query data (unless explicitly called to do so) from the model and if you do, beginResetModel/endResetModel just won't block
You seem to miss my whole point
-
How do you know they are meaningless? They just don't do what you expected them to do. How do you know that the view may not have an optimization so that at the moment it receives the modelAboutToBeReset signal, is stops listening or does other clever stuff such as clearing a cache or whatever magic needs to be done? I don't. And I certainly don't know that of any custom view living out there in the wild. What is done with the signal in the default Qt views, you can find out by inspecting the source code of those views yourself.
Anyway: where is it documented that the beginResetModel blocks a return to the eventloop? How should that even work? Like I said: I imagined it would block further signals (and that would have been possible to do), but it does not. But returning to the eventloop is something that is very hard to prevent.
If I miss your whole point, then perhaps you should try to explain it again, but this time without complaints that your assumptions of how Qt model view works don't match with reality. Then, perhaps, we can help you search for a solution or a workaround for your specific scenario. We all know that Qt model view is not perfect and that some use cases are hard to implement with it.
-
[quote author="Andre" date="1348649547"]How do you know they are meaningless? They just don't do what you expected them to do. [/quote]
Because if you don’t get returned to eventloop views simply can't query data from the model (with or without beginResetModel/endResetModel) by themselves (unless directly asked to do so, indeed). But if you do (despite beginResetModel) they will, which means they are still listening. Rather simple logic, right?
[quote author="Andre" date="1348649547"]Anyway: where is it documented that the beginResetModel blocks a return to the eventloop? How should that even work? Like I said: I imagined it would block further signals (and that would have been possible to do), but it does not. But returning to the eventloop is something that is very hard to prevent[/quote]
It's written in the docs that beginResetModel/endResetModel are used for safe resetting of the model internal data structures, which these methods fail to do. That's all
[quote author="Andre" date="1348649547"]If I miss your whole point, then perhaps you should try to explain it again, but this time without complaints that your assumptions of how Qt model view works don't match with reality[/quote]
These are really not my assumptions. It's not me who started talking about event loops
[quote author="Andre" date="1348649547"]Then, perhaps, we can help you search for a solution or a workaround for your specific scenario. We all know that Qt model view is not perfect and that some use cases are hard to implement with it[/quote]
I have already found a workaround (see above)
-
[quote author="deisik" date="1348648089"][quote author="peppe" date="1348647631"]
- beginResetModel/endResetModel will simply cause the emission of the model's modelAboutToBeReset / modelReset signals, update bookeeping information (persistent indexes), etc.
- views are allowed to ask for data() at any time, therefore returning to the event loop with the model in a "inconsistent" state is wrong[/quote]
Your first proposition contradics the second one. Views being allowed to ask for data at any time means that model should always be in a consistent state. And what about resetting model in this case?
[/quote]I think you're missing an obvious assumption, my fault: from the point of view of your code, Qt is a single-threaded and event-driven. (You can start other threads but that's out the question here, we're in the GUI thread.)
Therefore, the view's code that fetches data cannot be running at the same time you're updating the model. The views might fetch in response to the signals you emit when you call begin*/end* methods, but this makes no sense to me (and in any case, WHEN you're calling those methods, the model IS ALREADY in a consistent state. Either it's BEFORE any modification happened, or it's AFTER all modifications have been made).
-
[quote author="peppe" date="1348647631"]In your testcase you're simply adding rows/columns with a progress, and therefore you should actually be using beginInsertRows / beginInsertColumns; or, complete the model reset in each iteration, before returning to the event loop.[/quote]
Yes, just to show that the program will crash. In the actual model the data is changed completely, rows/columns can be added, removed or their number can remain the same, but all data is changed in all rows/columns
-
[quote author="peppe" date="1348651164"]Therefore, the view's code that fetches data cannot be running at the same time you're updating the model. The views might fetch in response to the signals you emit when you call begin*/end* methods, but this makes no sense to me (and in any case, WHEN you're calling those methods, the model IS ALREADY in a consistent state. Either it's BEFORE any modification happened, or it's AFTER all modifications have been made).[/quote]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this (even if there're no signals WITHIN this block or any other which is explicitly being called)
-
[quote author="deisik" date="1348651720"]That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]
And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.
-
[quote author="deisik" date="1348651720"]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]The fact that your application is single threaded DOES guarantee this.
-
[quote author="Andre" date="1348651988"]And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.[/quote]
It strictly follows from the docs
-
[quote author="peppe" date="1348652004"]
[quote author="deisik" date="1348651720"]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]The fact that your application is single threaded DOES guarantee this.
[/quote]
Well, except if you return to the eventloop, spin a new one or otherwise start processing events somewhere between calling the beginResetModel() and endResetModel(), of course... Which seems to be exactly what happened here. -
[quote author="deisik" date="1348652087"][quote author="Andre" date="1348651988"]And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.[/quote]
It strictly follows from the docs
[/quote]
Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed. -
[quote author="peppe" date="1348652004"]The fact that your application is single threaded DOES guarantee this[/quote]
Data queries by the views happen within beginResetModel/endResetModel block. The fact that the application is single threaded guarantees that query won't happen simultaneously with a single command which makes some data change in this block but this query still happens inside this block (interrupts it)
-
[quote author="Andre" date="1348652298"]Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed.[/quote]
I told "follows", do you get the difference? It's written at the beginning of the thread (no pun intended)
-
[quote author="deisik" date="1348652600"][quote author="Andre" date="1348652298"]Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed.[/quote]
I told "follows", do you get the difference? It's written at the beginning of the post
[/quote]
Ok, so let met get that back into fresh memory here:
[quote author="deisik" date="1328354153"]As per documentation, "you must call this function before resetting any internal data structures in your model or proxy model" and regarding its counterpart, endResetModel(), "you must call this function after resetting any internal data structure in your model or proxy model". Rational reasoning tells me that by beginResetModel() you declare your data being no longer valid (read unavailable) and by endResetModel() being valid again while changing it somewhere in between so that any views getting data from the model should shrink from quering data which is not yet ready. Everything seems consistent and coherent in this simple logic, right?[/quote]
There are a lot of assumptions in your reasoning above, that just are not valid. Yes, sure, it would be nice if Qt would somehow enforce all the above automaticaly (patches welcome, I think), but it doesn't, and the docs don't tell you that it does protect you from that.
I will agree with you that the issues with spinning an eventloop are not clearly documented, nor is the real function of the beginResetModel() function itself. Also, it isn't immediately clear that a progress dialog even does spin an eventloop or how it otherwise processess events. It clearly does (otherwise, it would not be able to update itself), but again: there is no documentation to warn you against side effects of that. I too would have expected the beginResetModel() method to do more work than it does. However, nowhere there is a promise in the docs that you are protected against queries in the way you seem to be deducing from the docs.
[quote author="deisik" date="1348652495"][quote author="peppe" date="1348652004"]The fact that your application is single threaded DOES guarantee this[/quote]
Data queries by the views happen within beginResetModel/endResetModel block. The fact that the application is single threaded guarantees that query won't happen simultaneously with a single command which makes some data change in this block but this query still happens inside this block (interrupts it)[/quote]
Sorry, but no. There are no "interrups" happening in Qt. It must be caused by some call made by you between the begin/end calls that triggers processing events or something like that. My bet (again: not checked against sources or tested myself): your calls to update your progress dialog are the culprit. -
There is very SIMPLE reasoning behind my assumptions. Views should in NO case query invalidated data from the model being reset, not even because the data has changed but because this may easily crash the program (e.g. you already deleted some rows/columns, but have not yet updated the variables holding their number). And this is what is meant by docs when you read that “you must call this function before resetting any internal data structures in your model or proxy model”
I don't really see why you don't understand these things