accessing simulation time inside processes

[quantverse]

Any idea how to access simulation time from within the process?

This code won't compile:

#![feature(generators, generator_trait)]
extern crate desim;
use desim::{Simulation, Effect, Event, EndCondition};

fn main() {

    let mut s = Simulation::new();
    let g = Box::new(|| {
        let tik = 0.7;
        loop{
            println!("tik {}", s.time());
            yield Effect::TimeOut(tik);
        }
    });

    let p = s.create_process(g);
    s.schedule_event(Event{time: 0.0, process: p});
    let s = s.run(EndCondition::Time(10.0));
}

The problem is accessing s from within the closure - it introduces immutable borrow of s with conflicts with the need to use the mutable borrow later. Any idea how to solve this without using Rc and RefCell?

[quantverse]

Looked into it again in depth. Introducing Rc and RefCell is not enough - a solution might be to introduce a Context object and move the time to there.

My first attempt (unpolished): https://github.com/quantverse/desim/commit/59e4701e0c020413d9b3599cc9d1918701864240

Modified example:

#![feature(generators, generator_trait)]
extern crate desim;
use desim::{Simulation, Effect, Event, EndCondition, Context};
use std::rc::Rc;
use std::cell::RefCell;

fn main() {

    let ctx = Rc::new(RefCell::new(Context::new()));
    let mut s = Simulation::new(ctx.clone());
    let g = Box::new(move || {
        let tik = 0.7;
        loop{
            println!("tik {}", ctx.borrow().time());
            yield Effect::TimeOut(tik);
        }
    });

    let p = s.create_process(g);
    s.schedule_event(Event{time: 0.0, process: p});
    let s = s.run(EndCondition::Time(10.0));
}

What do you think? I would really prefer a solution without using Rc/Refcell but not able to come with any (I am quite new to Rust)...

[garro95]

I like the solution. Maybe the context could be Pinned, but it's new syntax and I am not sure whether it can be applied in this case

[garro95]

It would be easier if it was possible to resume the generator with arguments, as the context could be passed by the simulation driver to the process at each resume.

[quantverse]

I like the solution. Maybe the context could be Pinned, but it's new syntax and I am not sure whether it can be applied in this case

Thanks, I would still prefer to avoid using Rc and RefCell whatsoever, but no idea how to do it without it. All generators must capture a pointer or reference to the context, so the only option would be that Simulation methods all work with self directly (claiming ownership). I don't like that idea much.

Why would you Pin the context? I assumed that pinning is mostly useful for self-referential structs and generators only...here we use the reference counting / shared ownership to maintain the context...

It would be easier if it was possible to resume the generator with arguments, as the context could be passed by the simulation driver to the process at each resume.

That would be the best solution indeed, but that feature is still in the Pre-RFC state: https://internals.rust-lang.org/t/pre-rfc-generator-resume-args/10011

Unfortunately I have to start developing the simulation ASAP...

[garro95]

Do you think we can follow the current implementation of the await! macro as explained in that thread in order to update this later on, when the RFC will be stabilized?

[quantverse]

Honestly I don't really like the idea of using the await! macro for this...I guess for the time being I will just use my hack, the proper idea really seems to wait for the generator resume arguments...

[garro95]

I did not mean to use the await macro directly, but to use the same strategy used in that case. But I am not sure it is feasible.

[quantverse]

If you mean using the TLS like they do - I think it is more of a hack than a appropriate implementation...

[garro95]

It is now possible to resume generators with arguments. The generators implementing Processes must now accept resume arguments of type SimContext. Calling it's time() method it is possible to know the elapsed simulation time.