ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007495 | Part 01: TTCN-3 Core Language | New Feature | public | 22-08-2016 15:09 | 04-01-2019 16:13

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.8.1 (published 2016-07) |
Target Version | 4.11.1 (published 2019-05) | Fixed in Version | 4.11.1 (published 2019-05) |
Clause Reference(s) | 21.3.2
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007495: out, inout and return value should be assignable via the done/killed statement redirect

Description

At the moment, it is allowed to start functions that have inout or out parameters or return clauses but the result of the computation for these parameters/the result cannot be accessed.
The verdict of a component can already be assigned via redirect statement, so it should be feasible to extend that to also include possible value/param clauses to assign the values of out/inout parameters/the return value in a deterministic way back to their original parts.
function f(out integer p_o, inout integer p_i) return integer {}
ptc.start(f(v_o, v_i));
ptc.done -> v_verdict value v_result param(v_o := p_o, v_i := p_i)
or alternatively
ptc.done -> v_verdict value v_result param(v_o, v_i);
(the short form should be the list notation supplying for all out or inout parameters).
The only open question is the semantics when a ptc is stopped during such a behavior. But here, I would say the end-result should be the values of the parameters at the time of the stop statement. If no assignment has taken place during the behavior, the original value is returned. In that way, the function would behave exactly as if called locally. The return value will be unbound if the behavior was stopped before the return statement was executed.
This way, there would be no shared memory between components and it is clear when the variables are changed and by whom (i.e. only by the owning component), so no read-write conflicts can occur in that regard.
If the connection between start and stop is too loose, the start statement could give back a handle (like activate) which could then be used by the done statement as reference.
var behavior b := ptc.start(f(i,o));
ptc.done(b) -> ...

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007598 | closed | Gyorgy Rethy | Part 01: TTCN-3 Core Language | Invalid restriction on formal template parameters
related to | 0007786 | closed | Tomas Urban | Part 06: TTCN-3 Control Interface | TciCallparameterListType needed to implement component call operation

Attached Files | CR7495.docx (158,806) 27-10-2017 10:46 http://oldforge.etsi.org/mantis/file_download.php?file_id=3721&type=bug CR7495-v2.docx (181,450) 27-10-2017 14:31 http://oldforge.etsi.org/mantis/file_download.php?file_id=3724&type=bug CR7495-v3.docx (183,174) 19-07-2018 15:52 http://oldforge.etsi.org/mantis/file_download.php?file_id=3779&type=bug

Issue History
Date Modified | Username | Field | Change
22-08-2016 15:09 | Jacob Wieland - Spirent | New Issue |
22-08-2016 15:09 | Jacob Wieland - Spirent | Status | new => assigned
22-08-2016 15:09 | Jacob Wieland - Spirent | Assigned To | => Jacob Wieland - Spirent
15-11-2016 10:30 | Jacob Wieland - Spirent | Note Added: 0014245 |
15-11-2016 11:21 | Jacob Wieland - Spirent | Note Added: 0014246 |
17-11-2016 13:53 | Jens Grabowski | Note Added: 0014306 |
17-11-2016 13:53 | Jens Grabowski | Target Version | v4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
06-06-2017 11:44 | Jens Grabowski | Relationship added | related to 0007598
05-09-2017 09:49 | Jacob Wieland - Spirent | Note Added: 0014813 |
26-10-2017 16:49 | Jacob Wieland - Spirent | Note Added: 0014902 |
27-10-2017 08:56 | Jacob Wieland - Spirent | Note Edited: 0014902 | bug_revision_view_page.php?bugnote_id=14902#r446
27-10-2017 10:46 | Jacob Wieland - Spirent | File Added: CR7495.docx |
27-10-2017 10:47 | Jacob Wieland - Spirent | Note Added: 0014908 |
27-10-2017 10:47 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
27-10-2017 10:47 | Jacob Wieland - Spirent | Status | assigned => confirmed
27-10-2017 14:31 | Tomas Urban | File Added: CR7495-v2.docx |
27-10-2017 14:32 | Tomas Urban | Note Added: 0014920 |
27-10-2017 14:32 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
01-11-2017 15:21 | Jacob Wieland - Spirent | Note Added: 0014921 |
01-11-2017 15:21 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
05-01-2018 13:30 | Gyorgy Rethy | Target Version | v4.10.1 (published 2018-05) => 4.11.1 (published 2019-05)
11-01-2018 11:50 | Jacob Wieland - Spirent | Note Added: 0015026 |
19-07-2018 15:52 | Tomas Urban | File Added: CR7495-v3.docx |
19-07-2018 15:53 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
19-07-2018 15:53 | Tomas Urban | Status | confirmed => assigned
19-07-2018 15:57 | Tomas Urban | Note Added: 0015180 |
20-07-2018 09:10 | Jacob Wieland - Spirent | Note Added: 0015186 |
20-07-2018 09:10 | Jacob Wieland - Spirent | Status | assigned => resolved
20-07-2018 09:10 | Jacob Wieland - Spirent | Fixed in Version | => 4.11.1 (published 2019-05)
20-07-2018 09:10 | Jacob Wieland - Spirent | Resolution | open => fixed
20-07-2018 09:10 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
20-07-2018 09:20 | Jacob Wieland - Spirent | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
20-07-2018 09:20 | Jacob Wieland - Spirent | Status | resolved => feedback
20-07-2018 09:20 | Jacob Wieland - Spirent | Resolution | fixed => reopened
20-07-2018 09:20 | Jacob Wieland - Spirent | Status | feedback => resolved
20-07-2018 09:20 | Jacob Wieland - Spirent | Resolution | reopened => fixed
20-07-2018 09:20 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
09-10-2018 09:38 | Tomas Urban | Relationship added | related to 0007786
04-01-2019 16:13 | Gyorgy Rethy | Note Added: 0015295 |
04-01-2019 16:13 | Gyorgy Rethy | Status | resolved => closed

Notes

(0014245)
Jacob Wieland - Spirent
15-11-2016 10:30

to allow static analysis of the done statment, the syntax should be made even more explicit:
var behavior := ptc.start(f(...));
ptc.done(b,f) -> [verdict v_verdict] [value v_value] [param(...)]
The f in the done statement could be any function reference (i.e. also a function variable).
The static analysis would check the param list and value types against the signature of the given function reference. The runtime would check whether the behavior is an actual instance of that function reference. If these checks fail, it would be an error.

(0014246)
Jacob Wieland - Spirent
15-11-2016 11:21

@STF discussion:
var behavior v_handle := ptc.start(f(...));
v_handle.done(f:{p_out := ?, p_inout := ?} value ? @verdict value ?)
-> value v_result
@verdict value v_verdict
param(v_out := p_out, v_inout := p_inout)
or direct combination:
ptc.start(f(...)).done(...) -> ...
all the matching parts and all the redirect parts are optional, the only non-optional thing is the f:<template> to allow checking types of return and parameters against f.
A simple case would be: v_handle.done(f:?) -> value v_result
The statement only matches in case the function returns gracefully (i.e. by using a return statement or for non-returning functions, reaches the end of the function body. It does specifically not match if the component is stopped either from outside or from inside.

(0014306)
Jens Grabowski
17-11-2016 13:53

Shifted to 2017 version.

(0014813)
Jacob Wieland - Spirent
05-09-2017 09:49

Thinking more about this, I think I would prefer to augment the component-done statement with this functionality rather than invent a new type.
In that way, you could also react on non-normal execution of the function (if functions are allowed to throw exceptions).
Example:
ptc.start(f(...);
alt {
[] ptc.done(f:?) -> value v_result verdict v_verdict param (v_out := p_out, v_inout := v_inout) {
...
}
[] ptc.catch(f, e) { // function raised exception that matches template e
... }
[] ptc.done { //terminated with stop or kill
}
[] t.timeout { // timeout how long to wait for termination of f
}
Another way would be reusing the call-statement syntax of ptcs by augmenting the start statement with a call-body:
ptc.start(f(...), 3.0) {
[] ptc.getreply(...) { // case where f returns gracefully
}
[] ptc.catch(f, e) { // case where f throws an exception that matches e
}
[] ptc.done { ... // case where f returns in another way
}
[] ptc.catch(timeout) { ... // case where f does not return
}
So, this would basically be the same syntax like for <port>.call, but using a ptc instead of a port for the getreply and catch statements.
In both cases, if you want to implement a blocking call, it would look simply like
ptc.start(f(...));
ptc.done(f:?) -> ...

(0014902)
Jacob Wieland - Spirent
26-10-2017 16:49 (edited on: 27-10-2017 08:56)

Simplified version: for a blocking call that waits indefinitely and optionally assigns the result and verdict: ptc.call(f(...)) -> value v_result verdict v_verdict; Robust version that can deal with timeout and exceptions thrown from f: ptc.call(f(...), t) -> value v_result verdict v_verdict catch (timeout) { ... } catch (exceptiontype:?) { ... }

(0014908)
Jacob Wieland - Spirent
27-10-2017 10:47

first proposal draft, please review I've left the exception handling part out by now because that is not part of the core language, yet

(0014920)
Tomas Urban
27-10-2017 14:32

I made several changes in the document (adding some missing parts and additional restrictions). Please check and if you are fine with it, please assign it to Jens so that he can take a look at the feature too.

(0014921)
Jacob Wieland - Spirent
01-11-2017 15:21

I don't fully agree with the change in restriction f as the result needs to be compatible with the variable and not the other way around (i.e. valueset(type of var) >= valueset(type of result) or more specifically result-value must be element of valueset(type of variable) or it is a testcase error).
If you look at the definitions for compatibility it always argues from the point of view of the value to be assigned, not from the type it assigned to.
All other changes are fine.

(0015026)
Jacob Wieland - Spirent
11-01-2018 11:50

While implementing this feature, I've run into a few problems on the TCI-level.
Using the TCI functions
tciStartTestComponentReq,
tciStartTestComponent,
tciTestComponentTerminatedReq,
tciTestComponentTerminated
there is no totally obvious way to propagate back the final values of the out/inout parameters (though that can be achieved internally by the CH implementation)
and there is no good way to propagate back the result value.
I propose to enhance TciParameterList with an additional function/method getResult() which returns the handle for result propagation and is shall return the value-target variable for calls.

(0015180)
Tomas Urban
19-07-2018 15:57

I changed the terminology a bit: (un)successful termination => (in)complete execution and added necessary explanation of these terms. There are also two new additional rules: 1. Implicit stop of the behaviour in case of timeout 2. No assignments in case of incomplete execution Please check.

(0015186)
Jacob Wieland - Spirent
20-07-2018 09:10

To me this looks fine and complete, so I set this to resolved.

(0015295)
Gyorgy Rethy
04-01-2019 16:13

Added to draft V4.10.2.