Implement an efficient process pool for sandboxing evaluation of foreign computations about unison HOT 9 CLOSED

Sure thing

from unison.

I'll take this on, if no one else is working on it

from unison.

Sure, though can you prioritize finishing up the key-value store bindings,
at least when you aren't bottlenecked by me needing to review/merge stuff?

On Fri, Apr 15, 2016 at 1:28 PM sfultong [email protected] wrote:

I'll take this on, if no one else is working on it

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#24 (comment)

from unison.

I started looking into this and have a few questions:

• Why does the evaluate function take a MaxProcesses? I would think MaxProcesses would be an attribute of a Pool and therefore be a parameter of the pool function.
• How does a client of Pool get access to process IDs (which are needed by evaluate and kill)? Seems to me that process IDs should be internal to a Pool.

I think it would help me to see how some client code would use a Pool. In particular, I'd like to see the interaction between a Pool and its worker processes.

from unison.

@tmciver

Why does the evaluate function take a MaxProcesses? I would think MaxProcesses would be an attribute of a Pool and therefore be a parameter of the pool function.

I think you're right. Not sure what I was thinking there. Let's go with that.

How does a client of Pool get access to process IDs (which are needed by evaluate and kill)? Seems to me that process IDs should be internal to a Pool.

With the API I gave, the client of Pool just makes them up before calling evaluate. But now that you mention it I think it would be simpler for Pool to just invent them itself and return the ID it picks immediately:

evaluate :: Budget -> a -> IO (ID, IO (Either Err b)),

So the outer IO (ID, ..) completes immediately, and the inner IO (Either Err b) completes whenever the worker finishes.

I think it would help me to see how some client code would use a Pool. In particular, I'd like to see the interaction between a Pool and its worker processes.

I'm a bit hazy on this myself, but client code would just call the evaluate function, and maybe kill if a computation was taking too long. What the evaluate function computes is going to be determined by whatever the worker processes do.

The worker process would just read a stream of Packet a from standard in (you could use some other IPC mechanism but using standard in / standard out seems reasonable), using deserialize, call its evaluate function, catching any exceptions, and writing results incrementally to standard out using serialize. Packet might look something like:

data Packet a = Kill | Done | Eval a deriving (Generic)
instance Serial a => Serial (Packet a)

Kill would indicate that the most recently started computation should be killed, Done indicates the overall process should be shut down following completion of any outstanding evaluation, and Eval a is a new computation to evaluate. Within a worker process, only one thing will ever be getting evaluated at a time.

So the implementation of Pool is going to spin up several worker processes using the provided action, keep track of their state (whether busy or idle), and send them work to do over their standard in. The workers will receive a stream of work to do / control messages, will do work, and serialize results to standard out where they'll be read by the process where the Pool lives.

Do you think that gives you enough to go on, or do you have more questions? Obviously as stuff comes up we can talk more. :)

from unison.

@pchiusano Thanks for elaborating. I've started a branch in my fork for this work (there's no implementation yet): https://github.com/tmciver/unison/tree/process-pool.

A few more questions:

• You've changed the return type of evaluate to contain the ID of the process being used for the evaluation but what should be returned for the ID in the case where previously we would have failed fast with an InsufficientProcesses error?

• In the description of the API at the top of the page you say

  When evaluate gets called, serialize the thunk using the argument passed to pool.

  What is the thunk? Is it the value of type a? Isn't a thunk a function?

• Probably related to the above question: what is the function a -> IO b passed to the worker function? At first I thought it would be a function given to us by the client that we would then evaluate. But then I thought workers were an implementation detail of a Pool.

from unison.

@tmciver Okay, I have been giving this some thought, and realized that sandboxing can be done in a way that is more elegant and makes this process pool unneeded. So I'm going to close this issue. Really sorry to pull the rug out from under you. :( I'll be on the lookout for other bite-sized projects.

Briefly, the new design (which I'll write up in a post) is that nodes are much lighter weight things (many nodes can be running on a single machine), and you can even spawn nodes dynamically, using a new primitive like:

-- | Create a new local node, running in the specified sandbox
spawn : Budget -> Sandbox -> Remote! Node

Where Budget specifies an amount of compute resources (memory and/or time) and Sandbox is some description of the capabilities the returned Node is allowed access to. Some details to be worked out but you get the idea.

I think this is a more elegant approach. Any pooling of nodes can be done just using pure Unison code. And when sharing node references with others, you can choose to share a sandboxed node that has more limited capabilities.

For the implementation, each node will be backed by a single OS process if it's 'awake', or if it's 'asleep' it will just be backed by some bits on disk.

I'm going to do some prototyping of this architecture before committing to it, but once it is more solid I think there will be some good bite-sized pieces for others to work on.

from unison.

OK, no problem. Let me know when there's more work to do; I'm eager to contribute to this project and hone my skills!

from unison.

Cool. :)

from unison.