ni / grpc-labview

gRPC client and server support for LabVIEW
MIT License
88 stars 62 forks source link

Reentrancy Settings #198

Closed yijueli closed 1 year ago

yijueli commented 1 year ago

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. image image

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

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

fixed in PR #200

drjdpowell commented 1 year ago

Notes on Reentrancy settings in an API: