Re: new Cohttp interface progress

[David Sheets <sheets@xxxxxxxxxxxxxx>]

On Mon, Aug 6, 2012 at 3:53 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 6 Aug 2012, at 23:45, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
> wrote:
>>
>> On 6 Aug 2012, at 23:34, Anil Madhavapeddy wrote:
>>
>>> ...
>>> Anyway, the reason this is relevant to the list is because Dave wanted to 
>>> use Cohttp, but also because the IO.M technique should be useful for other 
>>> protocol implementations that need multiple threading backends (Xenstore 
>>> and DNS perhaps).  It would be good to figure this out before we embed Lwt 
>>> really deeply.  I'll do some more work on this tomorrow, but ideas 
>>> welcome...
>>
>> without having read through everything (it's been post-holiday-email all the 
>> way today - the joys!)...
>>
>> it's generally interesting how we choose to build these interfaces but my 
>> initial thought is -- why do you want to support alternative threading 
>> libraries?  elegance, or an actual reason? ;p
>>
>> it does seem generally worthwhile thinking this through though -- eg., i'd 
>> also like to know where we're up to with defining network/channel etc 
>> interfaces of suitable generality...
>
> Good question. It's because each threading library has different tradeoffs in 
> terms of performance.
>
> Lwt has very fairly fine-grained errors, and propagates exceptions as values 
> (i.e. "fail" vs "raise").
>
> Async has a different mechanism called Monitors, where errors are caught by a 
> separate function that keeps an eye on a chunk of computation. It has also 
> deprecated streams, and has Reader/Writer pipes in preference.
>
> You could also build a version of IO.M that uses native threads (where type t 
> would be a dummy type and not actually hold any state).
>
> The other *big* thing we would like is that the same protocol library works 
> on both strings and Io_pages. It should be possible to hide away the precise 
> choice of what we're writing into behind IO.M.
>
> Right now, there are about 5 forks of Cohttp that all implement some of these 
> variants (Io_page, Net.Channel, Lwt_bytes, Lwt_unix and threads).  It would 
> be quite wise to unify them :-)

A monadic syntax akin to pa_lwt would be appreciated. I am developing
an application of cohttp and I would find it quite annoying to have to
switch to explicit binding.

Is Async's interface fundamentally faster than Lwt's? In their present
implementation?

David

> -anil