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

Re: new Cohttp interface progress

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

> On 21 Aug 2012, at 15:18, Anil Madhavapeddy wrote:
>> On 21 Aug 2012, at 07:01, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
>> wrote:
>>> 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).
> ok, i buy the portability argument to some extent, though i thought that we 
> were trying to keep Lwt out of the core parsing libraries anyway, restricting 
> it to "polluting" just the server/client code itself?

Sure...and this way it's guaranteed to not pollute the core library due
to the functor preventing it.  I found a few places where Lwt-specific things
were used already. Also, all the cohttp forks existed for a reason: they were
all restructuring the same code, which is now hopefully more portable.

> having said all that, the discussion is rather moot if you've done it already 
> :)  certainly, there's nothing lost by having another layer of abstraction so 
> that the server and client code can abstract over the threading library.

Well, I'm wondering whether to apply this to the DNS code next (which is a
lot simpler, since most of it is non-Lwt parsing code).  I'd like to run
some more performance tests first, and prepare for the upcoming XenSummit
talk first though.




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