Instead of using a parent process / child process model, you could consider cutting out the parent process entirely and using SO_REUSEPORT <https://lwn.net/Articles/542629/> to handle multiplexing the single address / port combo to multiple worker processes. There's an example in Python here <https://github.com/grpc/grpc/tree/master/examples/python/multiprocessing> that illustrates this. This should extrapolate pretty straightforwardly to C++.
On Friday, July 12, 2024 at 10:12:22 AM UTC-7 Eugene Ostroukhov wrote: > gRPC is not designed for this scenario. gRPC closes all file descriptors > before forking so the connections would not be available in the client. > This is explicit expectation and is covered with this test case - > https://github.com/grpc/grpc/blob/master/test/cpp/end2end/client_fork_test.cc > On Monday, December 4, 2023 at 8:02:19 AM UTC-8 stefan pantos wrote: > >> Hi, >> >> Is it possible to create a GRPC server in C++ using a pre-fork worker >> model and can someone point me to an example. I see there are some C >> prefork related functions but I cannot find an example of using this and >> cannot quite see how it would work either. I did try myself using >> AddInsecureChannelFromFd but I didn't have much success not sure if it is >> me simply making a coding mistake or complete miss understanding of the use >> case. >> >> Incase it isn't clear what I want to do I'll outline the idea in more >> detail. >> A parent process creates, binds and listens on the incoming port. >> Then the child processes are forked, they then do an accept on the now >> shared file descriptor. Only one of the children will accept a connection >> and will end up handing that connection but any other connections coming >> will be handled by one of the other child processes. >> >> This is a method outlined in UNIX Network Programming, and I think is a >> method used in Apache Httpd. >> >> The reason I want to use this method is that I have a code base which is >> not thread safe and it would take a long time and a lot of trial and error >> to make it thread safe and perform well enough. We have used this method >> for other protocols with good effect but none of them are as good as GRPC >> in my opinion. >> >> Thanks for any help you can give me in advance. >> Stefan Pantos >> > -- 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 it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/86cd9f65-8791-492c-802d-0493705d82c2n%40googlegroups.com.
