@User002 wrote:
That does seem like a reasonable solution if I'm writing all custom code. It's maybe a bit more work to develop, maintain, but the design flow is clear and I guess it probably uses less memory.
But since I'm (currently) using the built-in PID vi which keeps track of its own state, I'd have to modify it to not track it's own state and instead take state as an input and updated state as an output. This seems like a lot of work.
Are there other pros/cons I'm not thinking of?
Depending on the scale, architecture, and future of your application, this kind of issue can come up more and more often in different places and require more convoluted workarounds to overcome. On large projects with lots of parallelism and a long tail of maintenance I avoid using reentrant "stateful" VIs like this at all.
So, paying the price of refactoring the code now to not rely on reentrant VI state can save you some technical debt down the road. The tradeoff is very circumstance dependent. It's really a software engineering point...
