Re: new Cohttp interface progress

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 6 Aug 2012, at 23:53, Anil Madhavapeddy 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.

hm- do you have pointers to any examination of this, or is it just well known?

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

in some ways the different ways they do things like error handling is (to my 
mind) a more interesting distinction :)  (unless the perf differences are 
genuinely significant and different in multiple real applications.)

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

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.

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

i guess the question i'm asking is - unify, or cull? :)

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