Reentrancy Settings

[yijueli]

Recently we have received the request of modifying the reentrancy of grpc client request VIs in order to improve the system performance from our customers. Request Link: https://github.com/ni/adas-replay-hil-internal/discussions/348

Among the gRPC VIs, we noticed the Client Unary Call.vim was all re-entrant.The DLL calls are also configured to support calls form multiple threads.

However, the caller --Unary VIs below that were generated by the grpc scripting tool were all non-reentrant.

Is there a specific reason to set those unary VIs to be non-re-entrant? If not, can we have a proposal to let the scripting tool to make those VIs to be re-entrant?

[ni-sujain]

@yijueli Initially it was mix and match where some VIs were shared clone re-entrant and some were non-reentrant. We changed some of the VIs to have Pre-allocated clone re-entrancy via ths PR #106 . At that point we only changed the VI's under grpc-lvsupport.lvlib. We can certainly try to make the client template VI's re-entrant. I am not sure about the impact on memory footprint though for ADAS

[eyesonvis]

It sounds like there is no known reason why those VIs need to stay non-re-entrant. I would recommend that the ADAS team implement this change and contribute it rather than waiting for LabVIEW R&D to implement it. FYI @gregr-ni

[gregr-ni]

Agree with the no reason to stay reentrant. Sumit has already created a PR though so unless there is more to do, the ADAS team shouldn't need to do anything.

[ni-sujain]

fixed in PR #200

[drjdpowell]

Notes on Reentrancy settings in an API:

• inlining is always effectively Preallocate; the setting for preallocate or shared does nothing in this case
• if it isn't being inlined, and there is no internal state, then a subVI should generally NOT be preallocated (as you seem to be doing here); use shared reentrant.
• consider non-reentrant for rarely-called subVIs (like "Create Server"). Non-renentrant is the most efficient for compliled code size and is generally easier to debug.