From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
So, i just found a bit of code with a parallell loop, containing a non reentrant vi, making it moot. I guess we've all been there, and those things can be hard to spot.
Suggestion: Mark reentrancy with an automatic small corner icon similar type def, e.g. in different colors depending on if it's Shared or preallocated.
G# - Award winning reference based OOP for LV, for free! - QestitVIPMGitHub
No, there are many other properties that one may find important enough to think it has to be a glyph for it on the icon. What makes reentrancy special? Maybe better to find a way to easily debug that scenario (like looking through each VIs setting manually, which doesn't take so much time).
Maybe you can identify a set of rules that applies to your application(s) for when a VI should be reentrant and make a test for that to catch it (VI analyzer?).
I've always wanted a better indicator of reentrancy (and a few other properties), but I also understand the perils of adding more and more glyphs to the diagram.
The idea of temporarily displaying these kind of things like for showing buffer allocations is an interesting idea. Another way is to globally select what layers/types of glyphs/properties to view. A bit like defining a view in a CAD application (house architect analogy here): Do we want a plumbing/electrical view, do we want to see the furniture or not, and so on. Even defining view-presets for specific purposes, like debugging reentrancy issues e.g.
VI Analyzer has a "Reentrancy" test that would have found this issue.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5