Open lc525 opened 4 years ago
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 yield
s 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!
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:
Effect
+ arbitrary additional state)on_event_processed
,on_resource_acquire
,on_resource_enqueue
,on_resource_release
SimResource
trait that allResources
implementProcesses
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.