[gRPC/C++] Single threaded server via select()?

[rkr...@gmail.com]

What's the easiest way of making a gRPC server that can run single-threaded in cooperation with other file-descriptor based operations? What I plan is a single threaded server that waits on available data on any number of file descriptors via select(), one of the file descriptors corresponding to the socket that I'm serving gRPC requests on.

I looked at the async hello world sample, but am unsure as to whether or not I can just call the HandleRpcs() member function whenever my select() pops...

I'm assuming (and thus looking for confirmation :-)) that this would also work with stream messages on the server? (I.e., more data is available, the select() pops, I call HandleRpcs() to dispose of the additional data, and everything is right with the world?)

Thanks in advance!

Cheers,
-RK

[Vijay Pai]

Hi there,

Sorry, what you're looking for is not supported by any current or planned gRPC APIs for C++.   Our completion queue is actually based on a pretty complex polling mechanism to enable multiple threads to poll on different FDs in the general case; it uses either poll, epoll, or iocp depending on the platform and number of open FDs. We don't have any way of integrating our completion queue polling with any other event processing mechanism - either using the application's polling mechanism to drive the CQ or using gRPC's polling mechanism (src/core/iomgr) to activate application FDs. I can only suggest using a separate thread for application-level select or perhaps using a single thread that alternates 0 timeout select with 0 timeout gRPC AsyncNext calls.

Best regards,

Vijay

[Matt Stern]

Hey Vijay,

Wondering if this advice still stands 5 years later :-)

Even if gRPC doesn't provide a Linux file descriptor, could it take a user-provided callback and invoke it when new items are added to the CQ? That way a single-threaded app using epoll() or similar wouldn't need to include a periodic "check CQ" call in the poll loop.

-- Matt