Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple clients at once. #11

Open
nfultz opened this issue Oct 23, 2017 · 4 comments
Open

Support multiple clients at once. #11

nfultz opened this issue Oct 23, 2017 · 4 comments

Comments

@nfultz
Copy link
Owner

nfultz commented Oct 23, 2017

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
Copy link
Collaborator

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
Copy link
Owner Author

nfultz commented Nov 13, 2018

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
Copy link

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
Copy link
Collaborator

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants