Alternative (sketch) proposal:
Track this via resource quota's, since we have an API that's supposed to
deal with this already.
I'd imagine one new API:
void grpc_resource_quota_notify_on_memory_change(
grpc_resource_quota* resource_quota,
size_t min_memory_usage,
size_t
Personally, for the API I am thinking it would be flexible if core exposed
a single global callback, e.g., "notify_of_change_in_memory(amount)", where
amount is positive or negative for alloc/free.
On Thursday, January 18, 2018 at 10:03:34 PM UTC-8, apo...@google.com wrote:
>
> Good point, I
Good point, I think that really anything consuming large/unbounded memory
should potentially be tracked.
As for the API, I am thinking:
- If the API is synchronous, we could provide a rough estimate of an object
upon it's creation that doesn't change throughout it's lifetime. Perhaps
the
Let's enumerate the things that need sizes in this grfc... At first cut I'd
suggest:
- channels
- servers
- calls
- completion queues
Do we also need slices, slice buffers?
What about metadata?
Server memory can change drastically over time since it also maintains a
list of channels and
Discussion of https://github.com/grpc/proposal/pull/55
this thread
supersedes https://groups.google.com/forum/#!topic/grpc-io/FPoXprcT0d4
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from
