[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [henshin-dev] UI responsiveness by threading
|
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