Re: [certi-dev] Time advancement

[Eric Noulard]

2010/11/22 Michael Raab <address@hidden>:
> Hi Eric,
>
> log is attached...

Ok the strange thing is that after state has been put to TICK_RETURN
because timeout has expired:
case TimeManagement::TICK_NEXT:
                        /* a callback was evoked decide how to continue */
                        if (tm->_tick_result   &&
                                tm->_tick_multiple &&
                                
1e-9*clock->getDeltaNanoSecond(tm->_tick_clock_start) <
tm->_tick_max_tick) {

                            tm->_tick_state = TimeManagement::TICK_CALLBACK;
                        }
                        else {
                                tm->_tick_state = TimeManagement::TICK_RETURN;
                        }
            /* Unconditional return */
                        return;

The rtia process goes back to the
RTIA::execute()

loop and:
              case TimeManagement::TICK_CALLBACK:
              case TimeManagement::TICK_RETURN:
                /* tick() waits until a federate callback finishes:
                 *   block until federate message comes
                 *   RTIA messages are queued in a system queue
                 */
                comm->readMessage(n, NULL, &msg_un, NULL);
                break;

which is a **non-timeout** wait for a libRTI-->RTIA message ??

The TICK_RETURN --> NO_TICK is done through another processOngoingTick
but I currently do not follow  the path ...

I did commit some changes in order to improve readability of the trace.
I'll do some more to night or tomorrow in order to get a clearer picture.

So Yes, I think that when the current tick is timing out **inside
processOngoingTick**
(and not during readMessage within RTIA::execute)
the automaton seems broken, but I'm not sure how to fix it.

Any patch proposal is welcome :-]

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org