Должен ли я разделить заглушки или каналы gRPC?

API gRPC C ++ для создания каналов возвращает shared_ptr. Сгенерированная функция NewStub возвращает unique_ptr. Однако я видел отчеты людей, имеющих проблемы пытаясь создать несколько экземпляров типа заглушки, совместно используя канал. Их решение состояло в том, чтобы поделиться заглушкой.

Из документации или API неясно, предназначен ли клиент для создания нескольких экземпляров заглушки, совместно использующих канал, или общей заглушки. Пожалуйста, уточните концептуальные отношения между заглушками, каналами и уникальными клиентскими подключениями.

Погружение немного глубже:
Сервер может обслуживать более одной службы, а конечная точка клиента может использовать один канал для подключения соответствующих типов заглушек к каждой из этих служб. Для этой цели ясно, что разные типы заглушек совместно используют один канал для связи с конечной точкой сервера. Ожидает ли gRPC только одного клиента на канал для данной услуги, или я могу иметь несколько клиентов на клиентской конечной точке, говорящих с одной услугой? Если разрешено, как мне получить несколько клиентов для данной услуги на клиентской конечной точке? Как сервер различает их как независимых клиентов?

Как в сторону, Этот ТАК пост указывает, что оба канала и заглушки являются потокобезопасными. (Пост специально для Java, но я предполагаю, что он переносится на C ++).