[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: new Cohttp interface progress
On 21 Aug 2012, at 00:03, Anil Madhavapeddy wrote: > On Tue, Aug 07, 2012 at 09:55:24PM +0100, Richard Mortier wrote: >> >> >> hm- do you have pointers to any examination of this, or is it just well >> known? > > It's simply because they have different semantics. There are some numbers > in this paper from 2010 on different concurreny mechanisms in OCaml: > http://hal.inria.fr/docs/00/49/32/13/PDF/lwc.pdf > It doesn't cover Async as it has only be open-sourced this year, but you > get the idea I hope... i get that there are a number of different ways of implementing this, and of designing the apis to be used; but i don't yet completely understand why it's useful to abstract them all behind a single monad, and then allow the programmer to choose their own implementation. and i certainly don't see that programmers are likely to be in a position to make an informed choice based on the performance impact of the implementation selected without going to a *lot* of work (possibly repeatedly). though it does suggest, at least to me, that some sort of sensible automated performance simulation/monitoring framework would make sense, and would require a wrapping of this stuff in a monad of some kind. > I'm porting my avsm/ocaml-github bindings over to use the new API to make > sure any issues are shaken out, and then I will write a Mirage Net.Channel > version that we can use on the website. Then, any core protocol parsing > changes will be shared across all the various backends, and we have a nice > reference for what Async, Lwt and Mirage-net code all looks like in one > place. cool :) >> by strings do you mean bigarray thingies? if so then i buy that - it >> would be nice to have a single encapsulated layer that meant that all >> the mirage protocol libraries could take a single dependency on it and >> be usable from any other ocaml program. > > Yeah. I haven't actually done this yet as I'd like to stabilise everything > else. However, it shouldn't be too hard to define a sub-set of the String > module and use that to directly read/write from Bigarray too. We will > have to port the Re regexp library first, but that should also be very > quick. cool.... -- 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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |