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
