Hi Stephan et al,

beside the fact, that we do not have macro expansion in TTCN-3 but
active defaults, I totally agree with Alexey that active defaults are
active defaults, independently where the alt statement is.

In addition I was also wondering where the infinite loop is. Alexeys
analysis is right.

BTW: If you would like to write a recursion you might consider using the
*check* operation on a port instead of timeout. As far as I now this is
the only non-consuming port-operation.

To come back to your question, I think that the current semantics is
fine, and that we really do not need further exceptions. Quite the
contrary, I would better ask for less exceptions that have been
introduced to prevent users to do something wrong, like blocked systems,
etc.


Best regards,

Theo




Alexey Mednonogov wrote:
> Stephan,
>
> The very first line of section 21.1 of [FEB-2003] edition of the standard
> reads as follows: "The default mechanism is evoked at the end of each alt
> statement" (what also implies macro expansions for standalone receiving
> operations), and I do not recollect any clause in the standard that would
> explicitly enforce suppression of default mechanism while the default
> itself is being executed.
>
> Given that, an assumption can be made that defaults can be attached
> recursively, and it is the responsibility of test suite developer to
> take this fact into account.
>
> I do not see any infinite recursion exactly in your example. Timer
> g_t1 will expire only once, so the timeout event for g_t1 will also
> match only once. At the point marked as "HERE", when as() is attached
> recursively second time as a default, "g_t1.timeout" will not match
> second time, so we don't go any further. No recursion, no headaches.
> Or am I wrong? Please correct me if so.
>
> Hope this helps.
>
> Alexey Mednonogov
> Software Engineer
>
> OpenTTCN Oy
> www.openttcn.com/
>
> Stephan Tobies wrote:
>
>> Hi,
>>
>> I have a question regarding default evaluation:
>>
>> Suppose we are evaluating an alt statement and then run into the
>> evaluation of the active defaults. Now, one of these defaults has a
>> matching alternative, and in the body of this alternative there is a new
>> alt statement with no matching alternatives. Should, in this case,
>> default handling be triggered [more or less recursively] for this inner
>> alt stmt, or should this alt statement then block?
>>
>> Example:
>>
>> module ts {
>>
>> type component CT {
>> timer g_t1;
>> timer g_t2;
>> }
>>
>> altstep as() runs on CT {
>> [] g_t1.timeout {
>> alt {
>> [] g_t2.timeout { // <-- HERE
>> setverdict(pass);
>> }
>> }
>> }
>> }
>>
>> testcase tc() runs on CT {
>> activate(as());
>>
>> g_t1.start(2.0);
>> g_t2.start(10.0);
>>
>> alt {
>> [] g_t2.timeout {
>> setverdict(fail);
>> }
>> }
>> }
>> }
>>
>> In this example, what should happen when g_t2 has not yet expired and
>> the execution reaches the point marked '<-- HERE' while handling the
>> outer default as? Should as be re-entered as a new default on that level
>> (which, in turn, causes as to be re-entered on yet another level of
>> default handling, indefinitely until g_t2 finally expires [or infinitely
>> if g_t2 is not running?]
>>
>> What should we do with such a situation?
>>
>> a) Stick with this semantics, allowing the user to shoot himself in the
>> foot - after all, this is not the only way to crash a TTCN-3 test suite/
>>
>> b) Treat default-handling during default-handling as a run time error
>> condition?
>>
>> c) Switch off default handling during default handling, i.e., block at
>> the end of an alt statement that is encountered during default handling?
>>
>> d) Use some modified form of default handling in the inner case?
>>
>> I really don't know - I tend toward a) or c), but I would like to hear
>> other opinions and/or clarifications.
>>
>> BR
>>
>> Stephan
>>
>> --
>> Stephan Tobies Sr. Research Engineer, Nokia Research Center
>> ~ Mobile Networks Lab, Protocol Engineering Group
>> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Work Phone: +49-234-9842262
>> Mobile: +49-163-9842405
>> Fax: +49-234-9843491
>> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>
>

ext Theofanis Vassiliou-Gioles wrote:

>
> Hi Stephan et al,
>
> beside the fact, that we do not have macro expansion in TTCN-3 but
> active defaults, I totally agree with Alexey that active defaults are
> active defaults, independently where the alt statement is.
>
> In addition I was also wondering where the infinite loop is. Alexeys
> analysis is right.


Yes it is - but as you mention below - it is indeed possible to
construct examples with infinite cycles, with check or, I guess, using
[else] in the altstep.

as() {
[else] {
alt {
[] t_not_running.timeout { }
}
}
}

This one will also run into an infinite cycle once triggered:
t_not_running is not running, hence does not timeout -> default
handling->as is execute and so on.

>
> BTW: If you would like to write a recursion you might consider using the
> *check* operation on a port instead of timeout. As far as I now this is
> the only non-consuming port-operation.
>
> To come back to your question, I think that the current semantics is
> fine, and that we really do not need further exceptions. Quite the
> contrary, I would better ask for less exceptions that have been
> introduced to prevent users to do something wrong, like blocked systems,
> etc.


Fine, if it is common understanding that the current semantics mean that
defaults shall be evaluated on each level, so be it. I agree that we
should reduce the number of exceptions, and TTCN-3 already gives the
user enough rope to hang himself with, some more inch won't hurt ;-).

S.

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Mobile: +49-163-9842405
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany