garro95 / desim

A discrete-time events simulation framework, written in rust, using the generator experimental feature

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

desim new features (monitoring, callback_api, queuing disciplines, schedulers)

lc525 opened this issue · comments

I'm trying to asses the opportunity for one or more pull requests that add some features to desim. Most of those are the result of my own needs for discrete event simulation, but I would like to see if there is wider interest:

Currently already done but in need of polishing (marked below) or in my near-term pipeline:

  • Improved monitoring, driven by user-provided data types (Effect + arbitrary additional state)
  • Event callbacks, currently implemented: on_event_processed, on_resource_acquire, on_resource_enqueue, on_resource_release
  • Allow for arbitrary resource queuing disciplines by providing a SimResource trait that all Resources implement
  • Schedulers (Time Sharing): I'm currently designing this so that sets of Processes can be logically run in a time-sharing fashion (each being given a time slice). This is more disruptive to the code as simulation steps are no longer entirely driven by resuming generators.

At the moment the new code lives in my own fork of desim in a "new_features" branch but that is just a messy experiment and separate pull requests would have to be teased from that. However, I don't plan on maintaining a separate fork if you are interested in the changes upstream.

I really appreciate your work.
I would like to have separate pull requests from this and also some use cases for the features.
Also, I would like to keep the generators based architecture, as it seems simpler to me. Maybe we could discuss on this, also to investigate if there is any alternative

Thank you

I'll clean up things and add concrete examples for each pull request. Most of this is motivated by simulating data processing pipelines and queuing where you need to then look at things like resource utilization, contention, latency distribution for processing individual items, etc.

I also like the generators-based architecture so I'm not proposing changing that. It's just that when processes need to be non-cooperatively preempted (say for simulating actual threads being preempted when running on a CPU), the current work on generators (in rust) is not finalized. In particular yields do not have the ability to return values (yet).

There's also https://github.com/whatisaphone/genawaiter for an implementation of generators in stable rust, where values can be also pushed into the generator after a yield. However, I haven't looked much at it yet.

Resuming generators with arguments has been implemented in nightly rust!