[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mirage + froc = self-scaling?

On Thu, Mar 28, 2013 at 11:18 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> Some background on FRP, and specifically the FROC self-adjusting library:
> http://ambassadortothecomputers.blogspot.co.uk/2010/05/how-froc-works.html
> The goal of this work is to encode the external dependencies of a Mirage 
> unikernel explicitly, so that changes can ripple through the various 
> computation units in a well-defined manner.  The tricky bit is that I/O 
> threads ('the outside world') need to be strongly separated from FROC ('the 
> configuration space')
> Consider the case of an ARP input packet, which needs to update a 
> configuration variable (the ARP table), but is in the middle of doing some 
> I/O.  However, we want to safely weave together static input (a static ARP 
> configuration) with the dynamic inputs, which is where Froctol comes from.  
> There are many, many cases of such undefined behaviour in conventional 
> operating systems: what happens to existing network sockets when a DHCP 
> server rebinds an IP address on your machine?
> Raphael, are your experiments with this from last summer available anywhere?  
> I couldn't spot them in your Github repo list.

They are in a repo of yours: https://github.com/avsm/ocaml-ld

The following comment (in lib/froc_lwt) is interesting. It list things
that should be avoided when mixing the two paradigms
(cooperative-threading and reactive).

(*DOs and DONTs
* DONT expose writables (because it exposes the next DONT to the user)
* DONT change and yield (or otherwise switch thread)
* This can lead to partial changes being propagated. If you need to change
* several values before propagation, treat all the changes as a critical
* section, and make sure you propagate before yielding.
* DONT bypass Froc_sa.bind by creating a new changeable, manually write and
* propagate.
* DONT implement events over changeables. This restriction ensures that the
* whole system (in particullar, the data-plan) will be reactive (although
* theoretically appealing, it is better, for performance reasons, to
* restrict the reactive part to the configuration-plan).
* DONT use read under a bind (to avoid inconsistencies) but
* DO use read when you are in the data-plane (and thus not threading the
* changeables around).

One thing that is quite important with Froc: you can set several
changes and push them in one go. Thus, when reconfiguring it is
important to not yield in between different changes (otherwise another
thread might push).

> -anil
> On 28 Mar 2013, at 11:05, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
> wrote:
>> hi all;
>> after a chat with anil at asplos, i've begun playing around with using Froc 
>> with Mirage (actually, in the first instance, using Froc with Lwt). FRP is 
>> probably a good approach to try and encode notions of self-scaling that 
>> we've talked about before -- so a Froc self-adjusting computation becomes 
>> the overall framework within which Lwt threads execute to handle IO.
>> if anyone wants to take a look at what i've done so far, code is in 
>> <https://github.com/mor1/froctal> (neat name, huh? :)
>> this is very much work in progress, so suggestions for nice ways to 
>> integrate Froc and Lwt gratefully received!
>> --
>> Cheers,
>> R.
>> This message and any attachment are intended solely for the addressee and 
>> may contain confidential information. If you have received this message in 
>> error, please send it back to me, and immediately delete it.   Please do not 
>> use, copy or disclose the information contained in this message or in any 
>> attachment.  Any views or opinions expressed by the author of this email do 
>> not necessarily reflect the views of the University of Nottingham.
>> This message has been checked for viruses but the contents of an attachment
>> may still contain software viruses which could damage your computer system:
>> you are advised to perform your own checks. Email communications with the
>> University of Nottingham may be monitored as permitted by UK legislation.

RaphaÃl Proust



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.