Re: [henshin-dev] UI responsiveness by threading

[Gregor Bonifer <gregor.bonifer@xxxxxx>]

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