Re: sc_pause

John,

I'm fine with the semantics of sc_pause/get_status. Especially
completing the full delta cycle is a Good Thing.

Apart from the interaction with Process Control (see my separate mail),
I just have one minor question wrt to sc_start() + event starvation,
which has not been finally decided in the first discussion, I guess.

IIUIC, sc_start( SC_ZERO_TIME ) and sc_start( time ) both leave the
state of the simulation in SC_PAUSED, when returning due to sc_pause()
or by reaching the requested simulation time, right? I agree with this.

But what happens with sc_start() without any arguments and
sc_get_status()? SC_PAUSED or SC_STOPPED?

Quote the LRM (5.2.1.5 in the latest draft):

 "If no pending timed notifications or time-outs exist, the end of
  simulation has been reached. So, exit the scheduler."

What exactly should "exit the scheduler" mean here? Should it be
possible to start the scheduler again? (The PoC simulator "supports" it
for delta cycles only, which feels like a bug to me.)

If the simulation shall not be restarted, SC_PAUSED doesn't seem to make
much sense. Maybe we should return SC_STOPPED then? Should we even
call the end_of_simulation callbacks?

Opinions?

Greetings from Oldenburg,
 Philipp

On 12/11/10 14:49, john.aynsley@doulos.com wrote:
> It seems we are all set. I will write up the sc_pause/sc_get_status
> proposal in the LRM. As usual, shout if you want to raise objections.
>
> John A

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.