Re: new Cohttp interface progress

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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 :-)

-anil