| Re: [henshin-dev] UI responsiveness by threading |
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
Attachment:
signature.asc
Description: OpenPGP digital signature