Add reentrancy as a source file setting in the build specification

[nanocyte]

Normally, in the development environment, I make everything nonreentrant just to facilitate debugging. But sometimes, there are small VIs that are called frequently from many callers where it would be nice if I could make them reentrant so they don't block each other when running as an executable.

[Dmitry]

I think this is a dangerous practice as changing VIs to reentrant can alter your application behavior. I would advise configuring all such VIs to reentrant in LV IDE, re-testing the app and only them making a build. No need in proposed option in that case.

[AristosQueue (NI)]

Early in my LV career, back when reentrant VIs weren't debuggable at all (you couldn't open separate block diagrams for each instance, which meant no breakpoints or exec highlighting), I tried creating some apps where I applied reentrancy during the build. I learned it was a really bad idea. Reentrancy is a concept that changes the very definition of the VI, and it is something that needs to be consciously decided by the programmer, just like the conpane. I accidentally introduced memory bloat (commonly), race conditions (rarely but it did happen), and just general timing changes that I didn't expect because I hadn't coded with reentrancy in mind.

Given that experience and my observation of users in the years since then, I oppose this idea. I'm not going to ask that NI decline it yet -- let's see what other users have to say on the topic.

[nanocyte]

What do you mean "back when"? Reentrant VIs still have highly limited debug ability in RT Even outside of RT, there's other ideas on the exchange where people want more debug abilities for reentrant VIs.

What about a use case where the VI in question is basically pure math? That's something you'd want to be processed on multiple cores in parallel. It wouldn't cause any race conditions because it's functional and it shouldn't cause any memory issues that a straight "inline" wouldn't also cause. So, I know the VI should be reentrant or inlined as a final product but I want to retain debug abilities in the dev environment.

[AristosQueue (NI)]

I always forget about the RT limitation. I've never really used RT outside of a few toy apps. My work is almost all Desktop and some FPGA.

> What about a use case where the VI in question is basically pure math?

Sure, it's fine on a case-by-case basis, but since nothing in the dev environment will break when someone adds state to the VI or some other refactoring, I'd still be against adding it in the build settings.

The right answer is not to enable this setting but rather to improve the debugging of clones.

[donkdonk]

[..]I make everything nonreentrant just to facilitate debugging[..]

Very dangerous habit indeed.

Some vi's have a completely different output depending on whether you check-mark reentrant execution or not.

General rule: as soon as data needs to be stored (shift register, feedback node) that has to be retrieved on the same location of your diagram in a next iteration, you'll have to use reentrant execution. Given that you have multiple identical vi's in your diagram.

PID controllers for instance need to store the integrating action of the previous iteration, therefore they must be set reentrant.

That being said, the debugging (or lack thereof) issue really bugs me at times. Especially with realtime.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.