Document that the gRPCid can be passed out of the async event structure as a way to handle concurrent calls to the same entrypoint

[rtzoeller]

I had asked about handling concurrent calls to entrypoints with long-running stream responses. The current grpc-labview architecture and examples push you to handle these directly in the event structure, which forces calls to the same entrypoint to be serialized -- breaking concurrent stream responses.

Fortunately everything seems to just work if you handle the messages outside of the event structure, e.g. in an asynchronous VI call launched from the event structure, or in a separate loop receiving the gRPCid in a queue.

In response to my original question I received this, which suggested filing an issue for the documentation gap.

You can dispatch the handling of the gRPC method anyway you want including async VIs. You do not have to completely handle the call in the event case itself. The event ID is valid and can be read from or written to until the method is completed or cancelled.

If the client cancels the call reading or writing will return an error.

If you read or write to the event after the method is completed or cancelled on the server, you will also get an error.

I don't know if this is documented anywhere. An issue should be filed for this.

AB#2493886