This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: ocaml?? why??

To: John Levon <levon@xxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: ocaml?? why??
From: Vincent Hanquez <vincent.hanquez@xxxxxxxxxxxxx>
Date: Mon, 06 Apr 2009 16:08:30 +0100
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>, Patrick Colp <pjcolp@xxxxxxxxx>, Alex Zeffertt <Alex.Zeffertt@xxxxxxxxxxxxx>, Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Delivery-date: Mon, 06 Apr 2009 08:06:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20090406135155.GA7928@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C5FA6BCE.2C57B%gscoker@xxxxxxxxxxxxxx> <f45b39c0-8c4a-41d9-bd07-0e48a87aa6d4@default> <20090406103321.GA26380@xxxxxxxxxxxxxxxxx> <49DA08E4.4000303@xxxxxxxxxxxxx> <20090406135155.GA7928@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird (X11/20090103)
John Levon wrote:
OCaml has been great to use. Programming the same functional tree store with advanced transaction merging capability in the C version would have been a major pain, compared to how (almost) easy it was in OCaml.

So, I'm interested: why?
The initial reason was getting rid of the on-disk database that also work as the mechanism for transaction merging (a language with a GC is good for that). However it became quite clear, that we could also solve the problem of transaction stalling through the immutable tree and also making transactions cheap (the tree representation is shared over all transactions) compare to copying the whole database over filesystem of the C version.

at this point, making the transaction cheap is almost a given because of the language good GC (not referenced base !). the merging mechanism is something like 50 lines at this point too, with minimum code modifications on operations since that's the normal tree operations. (the C version has the same "normal operation" policy by copying the whole database and just changing which database is actually being referenced)

So now the reason, why not to modify the C version .. first getting rid of disk database to the memory, is quite annoying to do (but relatively easy so far) .. then you need to solve the problem of transaction stalling. there's lots of ways i guess, but i haven't imagine a solution where the same thing that the ocaml code does become trivial in C. either you need to modify every operation to understand some kind of modification list so that the tree get modified only at commit time (compare to now, at every operations), or you need to implement some kind of immutable tree (careful the C language doesn't prevent you for modifying it) which *requires* a GC that you need to implement too (or take one of those implementation from somewhere ..).

there's lots of other small reasons too, like the static type system that protect a lot during development phase (xenstored is very annoying to test, since it requires for full testing, to reboot the machine), and it's still an asset when i need to prove that no unexpected type are going to appears somehow (try to do the same thing in python and have fun :).

But surely xenstored could be implemented in any language, but I certainly wouldn't want to be the one fixing the C one, or implementing a python xenstored !


Xen-devel mailing list