Re: mirage + froc = self-scaling?

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 28 Mar 2013, at 12:47, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:

> 
> On 28 Mar 2013, at 11:36, Anil Madhavapeddy wrote:
> 
>> to help nail the semantics down.  Each Froc cycle should spin up a new 
>> process
>> that runs its own Lwt thread, with explicit handoff between them for 
>> resources.
> 
> just trying to understand what you mean by this. i have to this point been 
> looking at having a Froc graph constructed from multiple cells (a tuple of 
> Changeable and setter function), and then having each Lwt thread capture one 
> of the setters so that it can push a new value into the Froc graph in 
> response to external IO. the bit i'm finding mildly tricky at the moment (or 
> was until today, which is mostly being about annual performance reviews :/ is 
> managing the Lwt thread pool correctly. (ie., calling Lwt_main.run on the 
> right things.)
> 
> (a) does this sound sane or am i missing the point?
> 
> (b) are you suggesting that each time an input comes in on an Lwt thread i 
> should spin off a new process and explicitly hand off resources, in order to 
> be completely clear what and where are the resources?  (primarily IO handles 
> and such like i guess?)

It's important not to treat Lwt and Froc as black boxes, but understand 
precisely what's going under the hood.  The libraries are all pretty simple at 
their core.

- Lwt keeps track of I/O resources (file descriptors) and timers (in a priority 
queue).  Its inner loop ends up in a select()-style call, and when something 
becomes runnable, the associated closure is invoked.

- Froc keeps track of configuration variables ("signals") and the control flow 
dependencies required to calculate variables that are dependent on other 
variables.  The update manager needs some environmental way of retrieving 
configuration updates that aren't specified within FROC.

The confusion (I think) arises from the fact that both Lwt and Froc are not 
reentrant libraries.  When you create an Lwt "thread", you're adding a value to 
a global structure.  This makes it very easy to inadvertently break the rules 
that Raphael pointed out in Froc_lwt about crossing the streams between the two 
libraries.

There are two solutions I see:

- Rewrite both Lwt and Froc to accept an explicit context that would make them 
both reentrant.  This would be quite intrusive, particularly for Lwt.

- Separate them with a hard process barrier, so you're simply unable to see the 
Froc module from the subprocess that is running the Lwt I/O code.  

The observant among you will notice that this architecture is very similar to 
the Mirari module that VincentB is currently working on.  You can consider 
Mirari to be the 'Froc configuration' end, and the VMs or UNIX binaries it 
spawns to be the 'Lwt I/O' end.

And the problem we're trying to solve is: "how can a Mirage VM talk back to 
Mirari and let it know that some configuration state needs to be changed.  For 
example, because a resource or runqueue is overloaded?".  In this situation, 
Mirari will get a notification from the VM about a config update, will 
recompile a new VM, spin it up, and execute a transition function across the 
two.  However, before implementing this in Mirari and Mirage, it would be *far* 
easier to prototype it as a simple UNIX-based standalone library.

The semantics behind the transition between the two Lwt processes resulting 
from a FROC update are what is currently completely undefined. Ideally, only 
genuinely new resources should be moved across, and any common resources (e.g. 
a network bridge) should be shared.  This is possibly related to the 'traceable 
data structure work' work that Jake wanted to implement in FROC, but never 
completed:
http://www.umut-acar.org/publications/pldi2010.pdf [PLDI 2010 paper]

Hope this helps (?)

-anil