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