1

Topic: competing flows of update of the form

There is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: (old) flow 1 was completed and sent to the main flow the message "to launch update with data retrieveds". At this moment it is launched and (new) flow 2 which too sends the message to the main flow "comes to an end to be updated with data retrieveds". What message will be delivered in queue of the main flow are races.

2

Re: competing flows of update of the form

Hello, _hum _, you wrote: __> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: __> (old) flow 1 was completed and sent to the main flow the message "to launch update with data retrieveds". During this moment (new) flow 2 which too sends the message to the main flow "is launched and comes to an end to be updated with data retrieveds". What message will be delivered in queue of the main flow are races. If this form - only a window in which something is shown to the user - that of anything terrible. Updated the latest data - and it is good. If this form - any report (report) follows  that the data in it at such situation was not overwritten. How to resolve - IMHO it is standard (krit/sections, ).

3

Re: competing flows of update of the form

Hello, AlexGin, you wrote: AG> Hello, _hum _, you wrote: __>> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: __>> (old) flow 1 was completed and sent to the main flow the message "to launch update with data retrieveds". During this moment it is launched and (new) flow 2 which too sends the message to the main flow "comes to an end to be updated with data retrieveds". What message will be delivered in queue of the main flow are races. AG> if this form - only a window in which something is shown to the user - that of anything terrible. Updated the latest data - and it is good.  that the last settled up, and it can be old calculation - total, display  corresponds to model. AG> if this form - any report (report) follows  that the data in it at such situation was not overwritten. AG> how to resolve - IMHO it is standard (krit/sections, ). How sections can help? There and then the problem how to distinguish events of old calculations from the new. The item with. To me  the decision: It is necessary instead of catching of messages from all flows, to catch it only from the last launched. For this purpose it is possible to use QFuture: QForm () {connect (&m_futureWatcher, &QFutureWatcher<int>::finished, this, &Model::updateForm);} void QForm:: update () {[ calculation, like m_future.cancel ();//m_future = updateAsync (GetDataFromModel ()); m_futureWatcher.setFuture (m_future);}

4

Re: competing flows of update of the form

Hello, _hum _, you wrote: __>... __> (old) flow 1 was completed and sent to the main flow the message "to launch update with data retrieveds". During this moment it is launched and (new) flow 2 which too sends the message to the main flow "comes to an end to be updated with data retrieveds". What message will be delivered in queue of the main flow are races. Simply it is not necessary to perceive it as race. Calculations need to be launched only for the ready data, in a separate flow. After the termination of calculations the data needs to be displayed. All changes of model in the course of calculations - it is ignored (a maximum - we install a flag that there were new changes). All remaining, described at you - an unnecessary overhead projector. A good example of that that is necessary - any graphic engines. The frame on the basis of the available data is drawn. The following frame needs to be drawn only on the basis of already something new. Yes,  falls a little, but there will be no superfluous calculations. But it is absolutely not critical, since data mapping does not influence in any way model and business to the logician.

5

Re: competing flows of update of the form

Hello, SaZ, you wrote: SaZ> Hello, _hum _, you wrote: __>>... __>> (old) the flow 1 was completed and sent to the main flow the message "to launch update with data retrieveds". During this moment is launched and comes to an end (new) a flow 2 which too sends the message to the main flow "to be updated with data retrieveds". What message will be delivered in queue of the main flow are races. SaZ> simply it is not necessary to perceive it as race. Calculations need to be launched only for the ready data, in a separate flow. After the termination of calculations the data needs to be displayed. All changes of model in the course of calculations - it is ignored (a maximum - we install a flag that there were new changes). This bad decision. At it the maximum wait time of update will be twice above, than at the instant response to model change. And for calculations of the order of several seconds it is critical (an update time delay in 2-3 seconds and 7-10 - are qualitatively perceived very much differently)

6

Re: competing flows of update of the form

Hello, _hum _, you wrote: __> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: I would enter the intermediate model in which did heavy  and signaled in a principal flow already given which it is necessary to update. __> (old) flow 1 was completed and sent to the main flow the message "to launch update with data retrieveds". During this moment (new) flow 2 which too sends the message to the main flow "is launched and comes to an end to be updated with data retrieveds". What message will be delivered in queue of the main flow are races. From what versions they like registered that that the call of slots will happen in the same order as emit signals.

7

Re: competing flows of update of the form

Hello, Igore, you wrote: I> With what versions they like registered that that the call of slots will happen in the same order as emit signals. Only not emit and connect.

8

Re: competing flows of update of the form

Hello, Igore, you wrote: I> Hello, _hum _, you wrote: __>> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: I> I would enter the intermediate model in which did heavy  and signaled in a principal flow already given which it is necessary to update. The question was in how in that case (when "signaled in a principal flow already given which it is necessary to update") to distinguish signals about end of old calculations from signals about end of the new

9

Re: competing flows of update of the form

Hello, _hum _, you wrote: __>>> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: I>> I would enter the intermediate model in which did heavy  and signaled in a principal flow already given which it is necessary to update. __> the question was in how in that case (when "signaled in a principal flow already given which it is necessary to update") to distinguish signals about end of old calculations from signals about end new And what for? At me always GUI it is simple display of the last relevant data, to inform on that that now the latest tasks given never are displayed was not, well it is possible  to make in the beginning a signal and in GUI as that to inform the user that the freshest is displayed not most, color or , or generally all to clear if it so is critical. Well or at update given to select with color the changed data. What purpose in knowledge that the data not the latest is now displayed and still goes  a new portion?

10

Re: competing flows of update of the form

Hello, SaZ, you wrote: I>> With what versions they like registered that that the call of slots will happen in the same order as emit signals. SaZ> only not emit and connect. If a signal is connected to several slots, the slots are activated in the same order in which the connections were made, when the signal is emitted. I about other situation thought, there are some flows where emit newDataReceived (), and one slot longCalculation, and so this slot will be caused in that sequence as are made emit, the location in queue and then a call of slots in the same place is simple.

11

Re: competing flows of update of the form

Hello, Igore, you wrote: I> Hello, _hum _, you wrote: __>>>> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: I>>> I would enter the intermediate model in which did heavy  and signaled in a principal flow already given which it is necessary to update. __>> the question was in how in that case (when "signaled in a principal flow already given which it is necessary to update") to distinguish signals about end of old calculations from signals about end new I> And what for? At me always GUI it is simple display of the last relevant data, to inform on that that now the latest tasks given never are displayed was not, well it is possible  to make in the beginning a signal and in GUI as that to inform the user that the freshest is displayed not most, color or , or generally all to clear if it so is critical. Well or at update given to select with color the changed data. What purpose in knowledge that the data not the latest is now displayed and still goes  a new portion? You all the same not up to the end understood a problem. If at you old calculation is delayed (so that has already time to be fulfilled new) at you update will be produced as it should be - at first on the basis of the data of new calculation, and then on the basis of old. As a result there will be mismatches of the data of model and representation - that is while the model again does not change, the user will see the wrong data on the screen.

12

Re: competing flows of update of the form

Hello, Igore, you wrote: I> Hello, SaZ, you wrote: I>>> With what versions they like registered that that the call of slots will happen in the same order as emit signals. SaZ>> only not emit and connect. I> I> If a signal is connected to several slots, the slots are activated in the same order in which the connections were made, when the signal is emitted. I> I about other situation thought, there are some flows where emit newDataReceived (), and one slot longCalculation, and so this slot will be caused in that sequence as are made emit, the location in queue and then a call of slots in the same place is simple. And if emit have been made simultaneously?

13

Re: competing flows of update of the form

Hello, _hum _, you wrote: __> you all the same not up to the end understood a problem. If at you old calculation is delayed (so that has already time to be fulfilled new) at you update will be produced as it should be - at first on the basis of the data of new calculation, and then on the basis of old. As a result there will be mismatches of the data of model and representation - that is while the model again does not change, the user will see the wrong data on the screen. For calculation I implied the intermediate model: void ProxyHolder:: onNewData (RawData data) {data_ = data; if (calculationStarted_) {calculateAfter_ = true; return;} calculateAfter_ = false; calculationStarted_ = true; startLongCompilationIn ();} void ProxyHolder:: onCalculationDone () {calculationStarted_ = false; emit newCalculatedData (calcData_); if (calculateAfter_) {emit recalcWithLastData (data_);//QueuedConnection}}  and the remaining logic to add to taste, idea in that that is calculated only 1 portion of the data without interrupting calculation, we save the crude data for recomputation overwriting intermediate, in the end is checked on last we to the data settled up or not.

14

Re: competing flows of update of the form

15

Re: competing flows of update of the form

Hello, _hum _, you wrote: __> well then it about what spoke SaZ: SaZ>> Calculations need to be launched only for the ready data, in a separate flow. After the termination of calculations the data needs to be displayed. All changes of model in the course of calculations - it is ignored (a maximum - we install a flag that there were new changes). __> and I already answered, than it is bad Yes, I of that passed that, well add in the data time or the counter and do emit if only at the new calculated data the counter or date more than the last update. Such Author: _hum_ Date: 05.08 20:00 will work only if the data is updated not permanently, and that it will be possible to launch the program and never to see result.

16

Re: competing flows of update of the form

Hello, _hum _, you wrote: I>> Hello, SaZ, you wrote: I>>>> With what versions they like registered that that the call of slots will happen in the same order as emit signals. SaZ>>> only not emit and connect. I>> I>> If a signal is connected to several slots, the slots are activated in the same order in which the connections were made, when the signal is emitted. I>> I about other situation thought, there are some flows where emit newDataReceived (), and one slot longCalculation, and so this slot will be caused in that sequence as are made emit, the location in queue and then a call of slots in the same place is simple. __> and if emit have been made simultaneously? And? How they simultaneously get to queue? 1 slot, emit a little, rather the reverse.//emit QScopedPointer <QEvent> eventDeleter (event); data-> postEventList.addEvent (QPostEvent (receiver, event, priority)); eventDeleter.take (); event-> posted = true; ++ receiver-> d_func ()-> postedEvents; data-> canWait = false; locker.unlock (); QAbstractEventDispatcher* dispatcher = data-> eventDispatcher.loadAcquire (); if (dispatcher) dispatcher-> wakeUp ();//sendPostedEvents while (i <DATA-> postEventList.size ()) {//avoid live-lock if (i> = data-> postEventList.insertionOffset) break; const QPostEvent &pe = data-> postEventList.at (i);...//first, we diddle the event so that we can deliver//it, and that no one will try to touch it later. pe.event-> posted = false; QEvent *e = pe.event; QObject * r = pe.receiver; - r-> d_func ()-> postedEvents; Q_ASSERT (r-> d_func ()-> postedEvents> = 0);//next, update the data structure so that we're ready//for the next event. const_cast <QPostEvent &> (pe).event = 0; struct MutexUnlocker {QMutexLocker &m; MutexUnlocker (QMutexLocker &m): m (m) {m.unlock ();} ~MutexUnlocker () {m.relock ();} }; MutexUnlocker unlocker (locker); QScopedPointer <QEvent> event_deleter (e);//will delete the event (with the mutex unlocked)//after all that work, it's time to deliver the event. QCoreApplication:: sendEvent (r, e);...

17

Re: competing flows of update of the form

Hello, Igore, you wrote: I> Hello, _hum _, you wrote: __>>>> there is a form which is representation of any domain model (not to confuse with QAbstractModel). The model can change from time to time, accordingly, the form should react to signals of change of model and be updated. For update to the form it is necessary to fulfill beforehand on the basis of model transient data enough  on time calculation. It led to desire to issue calculation by a separate flow. And here there was a problem - if is admitted that model modification can happen continuously then, and starts of calculations on updates can be intersected (procedure of the first update was not up to the end completed yet, and the flow of performance another) begins. A question how to prevent a situation when new update gets into old because of a time delay in executions of flows? That is, if it is abstract how to get rid from: I>>> I would enter the intermediate model in which did heavy  and signaled in a principal flow already given which it is necessary to update. __>> the question was in how in that case (when "signaled in a principal flow already given which it is necessary to update") to distinguish signals about end of old calculations from signals about end new I> And what for? At me always GUI it is simple display of the last relevant data, to inform on that that now the latest tasks given never are displayed was not, well it is possible  to make in the beginning a signal and in GUI as that to inform the user that the freshest is displayed not most, color or , or generally all to clear if it so is critical. Well or at update given to select with color the changed data. What purpose in knowledge that the data not the latest is now displayed and still goes  a new portion? Well Igore, well e eat. A situation: | action t = 0 | the model passed time moment in state A (changed)-> start of a flow of 1 calculation for state A t = 1 | the model passed in state B (changed)-> start of a flow 2 calculations for state B t = 2 | completions of calculation of a flow 2-> update of the form by results of calculation for state B t = 3 | completions of calculation of a flow 1-> update of the form by results of calculation for state A total: the form at you will display old state A of model instead of displaying current state B. And form update can not happen generally any more (if the model state does not change any more)!

18

Re: competing flows of update of the form

Hello, Igore, you wrote: I> Hello, _hum _, you wrote: I>>> Hello, SaZ, you wrote: I>>>>> With what versions they like registered that that the call of slots will happen in the same order as emit signals. SaZ>>>> only not emit and connect. I>>> I>>> If a signal is connected to several slots, the slots are activated in the same order in which the connections were made, when the signal is emitted. I>>> I about other situation thought, there are some flows where emit newDataReceived (), and one slot longCalculation, and so this slot will be caused in that sequence as are made emit, the location in queue and then a call of slots in the same place is simple. __>> and if emit have been made simultaneously? I> and? How they simultaneously get to queue? 1 slot, emit a little, rather the reverse. I meant that the sense in such warranty big is not present, for parallel execution does not give possibility completely to supervise this order. For example, simultaneous performance emit in flows generates a situation like race when the manager himself solves as them to arrange (from whom to accept the message and to deliver in queue of the main flow to the first)

19

Re: competing flows of update of the form

Hello, _hum _, you wrote: __> I meant that the sense in such warranty big is not present, for parallel execution does not give possibility completely to supervise this order. For example, simultaneous performance emit in flows generates a situation like race, when the manager himself solves, as them to arrange (from whom to accept the message and to deliver in queue of the main flow to the first) If should supervise the order then it is necessary to use primitives of synchronization and by means of them not to admit such situations.

20

Re: competing flows of update of the form

Hello, SaZ, you wrote: SaZ> Hello, _hum _, you wrote: __>> I meant that the sense in such warranty big is not present, for parallel execution does not give possibility completely to supervise this order. For example, simultaneous performance emit in flows generates a situation like race, when the manager himself solves, as them to arrange (from whom to accept the message and to deliver in queue of the main flow to the first) SaZ> If it is necessary to supervise the order then it is necessary to use primitives of synchronization and by means of them not to admit such situations. Ingeniously

21

Re: competing flows of update of the form

Hello, _hum _, you wrote: __>... SaZ>> If it is necessary to supervise the order then it is necessary to use primitives of synchronization and by means of them not to admit such situations. __> All is ingenious ingenious simply. Though you strongly like to complicate to yourselves life.