BeginResetModel() not working



  • 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?

    But experience does not follow these considerations

    In my model I am using a QProgressDialog (qt 4.8.0) while inside beginResetModel/endResetModel block and the view attached to this model does try to query data from it showing garbage from partially rebuilt data (if not crashing). Presently, instead of changing an existing dataset I have to build a new one from scratch and then reassign half a dozen of pointers to get rid of this misconception. In my opinion this is neither the best nor the right thing to do - these data structures are greedy for memory and cpu, to put it mildly (mind, I ain't using a progress bar just for the fun of it)

    So my question, am I missing something with what beginResetModel/endResetModel functions are used for (and the meaning of the code they are supposed to enclose) or should I report a bug in case I am right in my assumptions?



  • From my experience this works without problems. I use it in my models and never ran into trouble. Without seeing any code we cannot comment any further.





  • I could reproduce that error with your test case. It's really strange and annoying. Thanks for opening the bug report, I've voted for it.



  • It feels like no one really cares out there. In the meantime I've managed a simple workaround by caching all items currently in the viewport and feeding them to the view while tacitly rebuilding the whole model in the background



  • At last someone deigned an answer in the bug tracker. They say it is not a bug, that beginResetModel and endResetModel can't be split by an event loop running. If they mean that the beginResetModel/endResetModel block should't be bothered from outside then the whole concept makes no sense, for its purpose as far as I get it is exactly to guarantee that the code within may not be interrupted for quering data, which beginResetModel/endResetModel surely fail to do



  • I think that Stephen is right in his comment, though I am not 100% sure. I'd (or you'd) have to dig in the code of QAbstractItemModel to see what this begin/end pair actually does. 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. 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 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 emit signals to the view besides these two in the data rebuild routine?
    [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, i.e. they shouldn't be used 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



  • 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



  • [quote author="Andre" date="1348653224"]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.[/quote]

    This is no secret. The problem is that the views should be FORBIDDEN to query invalidated data in ANY case (unless explicitly called to do so, of course). And beginResetModel tells views just that (which views don't follow). If you don't understand this, it's beyond my power to explain you this



  • I tried my best to explain you how I see this, and how I diagnose the problem, and where the problem in your reasoning is. For naught, clearly. It seems we won't get to an understanding on this issue. Like I said: I guess patches are welcome, to the documentation and/or the views.

    Edit:
    Interesting quote from the [[doc:QProcessDialog]] docs:
    [quote] warning If the progress dialog is modal (see QProgressDialog::QProgressDialog()), setValue() calls Application::processEvents(), so take care that this does not cause undesirable re-entrancy in your code. For example,don't use a QProgressDialog inside a paintEvent()![/quote]



  • By beginResetModel we explicitly declare that data in our model is no longer valid. What you're trying to say boils down to saying that there is some sense in quering invalidated data. What sense?


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.