Bugzilla – Full Text Bug Listing
| Summary: | Make xbase interpretation interruptable | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Sebastian Benz <sebastian.benz> | ||||
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | sebastian.zarnekow, sven.efftinge | ||||
| Version: | 2.0.0 | Flags: | sven.efftinge:
helios+
|
||||
| Target Milestone: | M6 | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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 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.
(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. pushed to master 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. Closing all bugs that were set to RESOLVED before Neon.0 Closing all bugs that were set to RESOLVED before Neon.0 |
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.