Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-dev] UI responsiveness by threading 
Hi Gregor,

On 09/15/11 11:28, Gregor Bonifer wrote:
Christian, I remember that someone mentioned listeners but I do not remember that we came to any decisions. Also, the protocol doesn't list the issue. But inserting noise-points to listen to might be a good basis for implementing the logging. Thereby we omit introducing a conrete dependence to any logging api. This would be nice since there were some concerns regarding the footprint. 

I agree!
We could encapsulate the listener collections together with the cancelation flag which needs to be passed through the unit application stack anyway.
Hm. I don't know yet whether it is really necessary to pass the monitor on every unit/rule application -- conceptually, this is the correct way to do it, but in terms of performance it might be better to introduce a canceled flag in the interpreter (same for the listeners collection). I'm still not sure about what is the best way to do it.
But more important for now would be to specify the interpreters behavior in case of cancelation. Is it desirable to see how far a UnitApplication has come at the point of cancelation or is it more important to maintain the integrity of the model by automatically performing a rollback? We could provide both behaviors but there should be a default.
I would not perform a complete rollback. What I would ensure though is that the last rule application is completed. For me, this is enough consistency ensurance... 

Ciao,
Christian



Regards,
Gregor

Am 14.09.2011 19:44, schrieb Christian Krause:

Hi all,
Gregor, you reminded me that during our meeting we shortly discussed that it could be useful to allow to register listener objects at the interpreter which get notifications when something interesting happens. I don't knwo whether this is actually useful for debugging or not, but we should keep it in mind for later... 

Ciao,
Christian


On 09/14/11 17:10, Gregor Bonifer wrote:
I have no objections towards your estimations. I'm just playing devils' advocate. Regarding the implementation I think the flag should be encapsulated, so each application has direct access to a flag-observer and no propagation is needed on change. Also such an object could later be extended to allow stepwise application for debugging purposes. 

Regards,
Gregor

Am 14.09.2011 16:32, schrieb Stefan Jurack:

Hi,

before Gregor brought up the topic in this mailing list, he and me
discussed that already and my arguing almost completely complies to that 
of Christian.
I am convinced as well that in 99,99% of all cases where JavaScript is
used in transformations, only rather simple evaluations take place. Thus 
I don't see the necessity of putting any effort in the cancellation of
JavaScript evaluations.

In detail, I prefer the solution, where a cancel-flag is polled before
the execution/application of units/rules, which then leads to a
finishing of the current thread.

Best regards,
Stefan



Am 14.09.2011 16:02, schrieb Gregor Bonifer:

Of cource, there is no goal one would try to achieve by intentional
hangup. But, this is a scenario which might occur with beginners
trying to test for limitations of henshin or during tool comparisons . 
This can easily be interpreted as a daunting example of immature tool
support.
Do you mean that the monitor should be included in the ScriptEngine
scope so one could use something like
"function(){while(!monitor.isCanceled()){}}"?

Regards,
Gregor

Am 14.09.2011 15:05, schrieb Christian Krause:

You have to assume a sane developer. Someone who uses an attribute
condition "function(){while(true){}}" should be punished anyway...

But seriously, it is the developers job to ensure responsiveness if
he writes his one units. So *he* (or she for that matter) must take
care of regularly checking the canceled flag himself. If he doesn't,
it's his own fault. Besides, in like 95% of the cases, JavaScript is
used only for simple attribute conditions (without loops) which
usually take only a split second.

Ciao,
Christian

On 09/14/11 14:54, Gregor Bonifer wrote:

Hi,
suppose you have just a simple rule with an attribute condition
containing "function(){while(true){}}" (and of course some
parameter's name). How would you propose to terminate the
ScriptEngine.eval(String) methode without Thread.stop()? Or is there 
a way I'm not aware of to check some monitor's cancelation-flag
while running ScriptEngine.eval(String) without using threads?

Aloha,
Gregor

Am 14.09.2011 14:38, schrieb Christian Krause:

Hi,
I have strong objections against Thread.stop() and I don't see a
conceptual or technical problem with using a canceled flag (as part 
of a progress monitor). The interpreter itself does not need a
cancel-flag. You can just pass a monitor object as an additional
argument on every call of a rule or unit application, including
units that are implemented using JavaScript (?).

Ciao,
Christian

PS: I'm not saying that we have to use Eclipse' IProgressMonitor
for this.

On 09/14/11 13:16, Gregor Bonifer wrote:

Hi,
I am currently looking into ways to interrupt long-running or
non-terminating UnitApplications. As mentioned at the henshin
developer meeting this is needed to ensure UI responsiveness. I
briefly discussed the issue with Stefan and our main concern was
the necessity of using the deprecated Thread.stop().

1) In a naive approach UnitApplication.execute() would be called
in its own thread which is supervised by an IRunnableWithProgress
which again calls Thread.stop() when its Monitor.isCanceled().
  - pro: On the one hand this would realize UI responsiveness
without the need to on introduce new code into the interpreter.
  - contra: On the other hand the resulting model would surely be
corrupt which is near fatal when using a graph contained in the
TransformationSystem.

2) Another approach would be to introduce execution state
information like a cancel-flag into the interpreter to detect
whether or not to continue. The flag would be set by a supervising 
IRunnableWithProgress like in 1).
  - pro: This would enable us to cancel without side-effects by
performing an undo of all applied rules.
  - contra: But there is no *known* way to propagate such a
flag-state to the javascript engine while running an infinte loop. 
If we intend to cover the case of JSE hang-ups we would need to
run the script execution in its own thread and call Thread.stop()
when the flag value changes.

If we decide that the use of the depecated Thread.stop() is
acceptable, there are no more contras and I would favor the second 
approach. But in case we consider Thread.stop() to be avoided, I
would prefer not to introduce any code into the interpreter until
we have some sort of wholistic concept for solving the issue.

Please comment.

Regards,
Gregor



_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev

_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev


_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev

_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev


_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev



_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev



_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev


_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev



_______________________________________________
henshin-dev mailing list
henshin-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/henshin-dev

Back to the top