Re: new Cohttp interface progress

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 21 Aug 2012, at 07:01, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:

> 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. 

Purely for portability, and not tie the core parsing unnecessarily to one
of the (many) concurrency libraries out there.  One of the problems/features
of Lwt is that it affects all the types so much by using it, due to Lwt.t
going everywhere that could potentially block.  At this this way, it's a 
somewhat more abstract one that can be ported to Async's Deferred.t or be
replaced with a unit when it's not needed (i.e. if someone adds deferred
cothreading to OCaml directly).

-anil