Optionally change when actions run

[Lucas-Morais-Freire]

Hi. First of all, thank you for the continued support to this useful lib. I would like to share an idea for the simulator that I think would be a neat feature. Actions are a very useful tool for the simulator and it works really well given it's premise, but I think it would be nice if there was an option for an action's function to be ran after the value for a memory location is returned. Even better, when a multi-address requisition is made, make it so that the actions are performed only after all values are returned.

This is why I think this is cool: when needing to update a large quantity of memory addresses, it could cause significant lag for a server + simulator to respond. A large number of registers need to be updated + a lot of data must be sent back to a client. Therefore, prioritizing returning the current values and performing the actions only after the server starts serving the data back gives the simulator time to update before the next requisition is received.

Here's how I believe the current pipeline is:

(multi addr READ server request received) -> [(run action) -> (get value) -> (run action) -> (get value) -> ... -> (run action) -> (get value)] -> (server responds) -> (wait) -> (server request received) -> ...

the section between square brackets represents all the lag from the value getting + actions running.

Here's how I believe the pipeline could be, optionally:

(multi addr READ server request received) -> [(get value) -> (get value) -> ... -> (get value)] -> (server responds) -> (run_action) -> (run action) -> ... -> (server request received) -> ...

therefore, the lag between the received request and the response would comprise only from value-getting (strictly necessary of course), and the actions could be ran during the waiting period between requests. And since the servers are async, we could even run actions while the server is doing IO operations.

[janiversen]

Thanks for you input, however "normal" actions execute very fast and do not cause any delay compared to transmission times.

it is a design choice to run the action before returning the result, because that way you control the result not the next result.

however as always pull requests are welcome, we are cuuently working on a new configuration simData, it is partly available on dev.