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

Re: OS.*



On 16 Aug 2013, at 07:47, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote:

> On 16/08/2013 12:42, Anil Madhavapeddy wrote:
>> The OS module is best thought of as analogous to the Cohttp.IO
>> functor.  It's the minimal support needed for building portable
>> applications that might run on several backends.
>> 
>> In the longer-term, it makes complete sense to break up OS into a set
>> of functors rather than the current pack hack, and to get Mirari to
>> instantiate the application by applying the correct backend.
>> 
>> However, the Xen-specific OS functions can and should be pulled out
>> from OS, leaving only the portable aliases (e.g. OS.Time) that*use*
>> the Xen functions but also have an implementation under UNIX.
> 
> Unfortunately Xs can't be pulled out because only one instance of Xs can be 
> ever instanciated (We don't support connection multiplexing to the xenstore).

We could modify OS to take a handle for all of its function calls.  This would 
let us spin up multiple instances if appropriate for the backend.  I can see 
this immediately being of use in the NS3 simulation backend, for instance.

That would solve your problem with Xenstore as well, right?  The OS handle 
could hold the multiplexing lock.

-anil


  • Follow-Ups:
  • References:

 


Rackspace

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