Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338487 - Make xbase interpretation interruptable
Summary: Make xbase interpretation interruptable
Status: CLOSED FIXED
Alias: None
Product: TMF
Classification: Modeling
Component: Xtext (show other bugs)
Version: 2.0.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: M6   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-28 18:13 EST by Sebastian Benz CLA
Modified: 2017-09-19 17:08 EDT (History)
2 users (show)

See Also:
sven.efftinge: helios+


Attachments
A cancelable XbaseInterpreter (29.48 KB, patch)
2011-02-28 18:13 EST, Sebastian Benz CLA
sven.efftinge: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Benz CLA 2011-02-28 18:13:13 EST
Created attachment 190009 [details]
A cancelable XbaseInterpreter

Currently it is not possible to interrupt the Xbase interpreter. In Xrepl, this means that when the user enters an infinite loop, there is no other way to stop the execution of the interpreter than to restart eclipse. It would be great to have an explicit way to cancel the interpretation. There are two possible solutions that come to my mind:

1) Check in XBaseInterpreter#internalEvaluate() whether the current thread is interrupted via Thread.currentThread().isInterrupted(). 
2) Pass in an optional CancelIndicator which is checked in XBaseInterpreter#internalEvaluate().

I attached a sample implementation for 2) together with a test that exemplifies the behavior. However, I am not perfectly happy with the solution, because it results in every method in XbaseInterpreter having an additional parameter (the CancelIndicator). But I think its a good starting point for further discussion.
Comment 1 Sebastian Zarnekow CLA 2011-03-01 02:05:15 EST
Hi Sebastian,

thanks for the patch. Unfortunately there was a race condition and
I'd assume the changes in http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/commit/?id=dbc04b621b58a9dd03e39d261618565352677f56 achieve the same, don't they?

Regards,
Sebastian
Comment 2 Sebastian Zarnekow CLA 2011-03-01 02:20:00 EST
Since the thread local approach does not work if I spawn a new thread in the interpreter, e.g. via new Thread(|{ .. some closue code here }).start, we should consider to adopt the current solution to the one which was attached here.
Comment 3 Sven Efftinge CLA 2011-03-01 02:42:14 EST
(In reply to comment #2)
> Since the thread local approach does not work if I spawn a new thread in the
> interpreter, e.g. via new Thread(|{ .. some closue code here }).start, we
> should consider to adopt the current solution to the one which was attached
> here.

Yes, makes sense.
Comment 4 Sven Efftinge CLA 2011-03-01 02:43:54 EST
pushed to master
Comment 5 Sebastian Benz CLA 2011-03-01 06:15:34 EST
Thanks for the quick fix. I also prefer the solution with the CancelIndicator being a member variable. I wasn't sure whether you wanted the interpreter to be stateless or not. That's why I added the CancelIndicator as an additional parameter to the *evaluate* methods.
Comment 6 Karsten Thoms CLA 2017-09-19 16:57:18 EDT
Closing all bugs that were set to RESOLVED before Neon.0
Comment 7 Karsten Thoms CLA 2017-09-19 17:08:34 EDT
Closing all bugs that were set to RESOLVED before Neon.0