nfultz / grpc

gRPC clients and servers in R
72 stars 24 forks source link

Support multiple clients at once. #11

Open nfultz opened 6 years ago

nfultz commented 6 years ago

Right now, server mode can only handle one client at a time - the first client must hang up before the server can begin processing the second request.

To fix this, for each request, we should run each response in a different thread drawn from a thread pool.

Initially I planned on using RcppParallel, but it's README explicitly says not to access any R APIs from its workers.

My alternative plan is modify the server callback wrapper code to call through mcparallel - this will preclude (theoretical anyway) windows support, but is the next step towards fully implementing the grpc api.

daroczig commented 5 years ago

As per my understanding, this will require starting multiple R processes to achieve this, so that's not that different than starting multiple actual grpc (as R pkg) workers and group those together with a load balancer of a service discovery agent or something, so I'm not sure if this is really important -- but I might miss something here. Do you have any use cases for this?

nfultz commented 5 years ago

It is quite a bit different from running multiple independent processes behind a load balancer. ?mcfork :

In a nutshell fork spawns a copy (child) of the current process, that can work in parallel to the master (parent) process. At the point of forking both processes share exactly the same state including the workspace, global options, loaded packages etc. Forking is relatively cheap in modern operating systems and no real copy of the used memory is created, instead both processes share the same memory and only modified parts are copied. This makes mcfork an ideal tool for parallel processing since there is no need to setup the parallel working environment, data and code is shared automatically from the start.

Something like this will be required if I'm ever going to get the streaming methods working.

dselivanov commented 5 years ago

This is the approach taken by Rserve and inherited by RestRserve. Works nicely and very performant. The issue is only when it is needed to change the state of the parent process. This is complex and requires not trivial inter-process communication.

daroczig commented 5 years ago

Oh, I was not aware of the fact that forks are using the same memory of unmodified objects, I thought each fork becomes an actual copy of current state - despite the fact that I have been using forks extensively :) Also thanks for the RestRserve pointer, looks great! I've been using Rapache quite a lot, it's great to see that nowadays there is an actual alternative!