From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id D7EA47FF9F for ; Mon, 7 Mar 2016 15:26:01 +0100 (CET) IronPort-PHdr: 9a23:Xqhl0hXyeiNeHVc4erJDFg/tQ/HV8LGtZVwlr6E/grcLSJyIuqrYZh2Ot8tkgFKBZ4jH8fUM07OQ6PC/HzxZqsva+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8KVM1wD2WH1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHj20+2AEX24Kvh1NCgnDpFGmD9ai+hf949t6xCCfdef/V7YzSHz2/qB3QRrigT0BMC8R/2Tei8g2h6Ve9kGPvRt6lqfPYICONLJXcarHYtoeDT5IUc9LSCVFW9LjMqMACuMAOaBTqIyr9AhGlge3GQT5XLCn8TRPnHKjmPBj3g== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=agarwal1975@gmail.com; spf=Pass smtp.mailfrom=agarwal1975@gmail.com; spf=None smtp.helo=postmaster@mail-qg0-f52.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of agarwal1975@gmail.com) identity=pra; client-ip=209.85.192.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of agarwal1975@gmail.com designates 209.85.192.52 as permitted sender) identity=mailfrom; client-ip=209.85.192.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="agarwal1975@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-qg0-f52.google.com) identity=helo; client-ip=209.85.192.52; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="agarwal1975@gmail.com"; x-sender="postmaster@mail-qg0-f52.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CQBQBxjt1WeTTAVdFcgm6BHm0GqgsqiGqHKYFpIYVuAoEhBzoSAQEBAQEBAQEQAQEJCwwIIS+CLYIUAQEBAwESER0BGxILAQMBCwYFCw0NHQICIQEBEQEFAQoSBhMSAg6HagEDCggOokKBMT4xizaBaoJXhRoKGScDClGDdgEBAQEGAQEBAQEBAQESAQUKBIpGgj2BTF6CU4E6BYYcDId8iH4IgRiES4YVgXWCLoxMhwyGCxEegQ8PGAqCJwocgWYeLgGJPAEBAQ X-IPAS-Result: A0CQBQBxjt1WeTTAVdFcgm6BHm0GqgsqiGqHKYFpIYVuAoEhBzoSAQEBAQEBAQEQAQEJCwwIIS+CLYIUAQEBAwESER0BGxILAQMBCwYFCw0NHQICIQEBEQEFAQoSBhMSAg6HagEDCggOokKBMT4xizaBaoJXhRoKGScDClGDdgEBAQEGAQEBAQEBAQESAQUKBIpGgj2BTF6CU4E6BYYcDId8iH4IgRiES4YVgXWCLoxMhwyGCxEegQ8PGAqCJwocgWYeLgGJPAEBAQ X-IronPort-AV: E=Sophos;i="5.22,551,1449529200"; d="scan'208,217";a="167456321" Received: from mail-qg0-f52.google.com ([209.85.192.52]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 07 Mar 2016 15:26:00 +0100 Received: by mail-qg0-f52.google.com with SMTP id t4so96904178qge.0 for ; Mon, 07 Mar 2016 06:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z1nh0XdBADwbAPfxEskmCteEnM4/OLOxwBa1OlXte3I=; b=kF7rlTfLeQOH8CeAFiEf4emZdSrXp7A5HnyLzuEkFZSc5YbQBptLFwPJRklM4lKHa1 M8t+VkqiBFzUoJMIpN8c1SSO0exRaGi7WFgt5G3eLOEFRj0h5wtyrUXAnRWyyXe6F8NG CFnipLRmtQ+lSj4osyTl7xyNh449FoQfORiFaWHAufRbVKLBARsA3lavrjrE+MQBdFkM kqbIJCUU2G1SvV8Yq8voUOhLuLJCrttgtjSEeoiYZJCY8GLD5XbiikYW9MgXs4REcDV4 z5GoRPHTV1yPigf1/3FCczx2g1f2aSZJ79zYZW0USOA1cVjkWPQ4v1zJVCJ3XOTQUPy/ SMnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z1nh0XdBADwbAPfxEskmCteEnM4/OLOxwBa1OlXte3I=; b=cZdAI84oXMAyDWAN4IoD9O6GRaITTRp6bxVw4J5lObGAKeapNPBMFG+13OIBoMfHzQ qvLohCdNS00WKyXBm1V/kV9eEx3VNj3MfxcKAWiQM31og5LATmRSQ8qwbXh3939QwDeA uOvWi/PU2JVMx9eBopm7T02Hk2MTfBPEYCNEA5XpNdu9TLnhnxE/HYlLO4G+D6ff5GAG EvCeTjzjANV+9xj+VemvrAba3ufBGA4Lu2ohA2/I4BNtK2Ckx6B4E6CsMLWG3dREjzy0 yG6JPlwL85+xPkOyry/OBpNDdWSRjcNhxri1BNmTuCJ8GgMHBgVsTCBdp1NxdoiQ67oQ ixzQ== X-Gm-Message-State: AD7BkJKAfksQKB89yFbz/RwG0nRyuSPvQOcAcE/5RdoDWtqwXtraSS5J200/VLHFcd9uXbduAInIgzz97huHVA== X-Received: by 10.140.38.104 with SMTP id s95mr27856551qgs.7.1457360758806; Mon, 07 Mar 2016 06:25:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.158.82 with HTTP; Mon, 7 Mar 2016 06:25:39 -0800 (PST) In-Reply-To: References: <86oaaqahc1.fsf@gmail.com> <20160307090859.GF30630@nunchakus.loria.fr> From: Ashish Agarwal Date: Mon, 7 Mar 2016 09:25:39 -0500 Message-ID: To: Yotam Barnoy Cc: Simon Cruanes , Malcolm Matalka , Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a11c1303256a2a5052d763e65 Subject: Re: [Caml-list] Question about Lwt/Async --001a11c1303256a2a5052d763e65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Also, what happens to general utility functions that aren't rewritten for Async/Lwt -- as far as I can tell, being in non-monadic code, they will always starve other threads, since they cannot yield to another Async/Lwt thread. There is Lwt_preemptive.detach and Async's In_thread.run to get around this. > It seems that Lwt is more popular in the community outside JaneStreet than Async (if only by looking at its reverse dependencies on opam.ocaml.or= g). There has been posts about this, for instance http://rgrinberg.com/blog/2014/12/11/abandoning-async/ . I'd be wary of drawing conclusions from one blog post and even from opam. I think the answer is: both are used a lot. Also depends on what you mean by "a user". It's not too useful to count Jane Street's packages and one barely used package on opam both as 1. A lot of code is not on opam. > Is there an existing compatibility library functorized over the intersection of Async and Lwt? That would make being compatible with both much easier. Most people provide this internally for each of their projects, e.g. Cohttp= 's IO signature . However, we have quite a few projects that needed this abstraction, so duplicating this code in each repo seemed wrong. Thus we developed future , which was recently released in opam. On Mon, Mar 7, 2016 at 9:06 AM, Yotam Barnoy wrote: > Is there an existing compatibility library functorized over the > intersection of Async and Lwt? That would make being compatible with both > much easier. > > On Mon, Mar 7, 2016 at 4:08 AM, Simon Cruanes > wrote: > >> Hi, >> >> It seems that Lwt is more popular in the community >> outside JaneStreet than Async (if only by looking at its reverse >> dependencies on opam.ocaml.org). There has been posts about this, for >> instance http://rgrinberg.com/blog/2014/12/11/abandoning-async/ . >> However, if you're writing a library, it is good taste (if possible) to >> parametrize you code over an "IO" monad that will be easy to instantiate >> with either Async or Lwt (or the trivial blocking monad where 'a t =3D 'a >> and (>>=3D) x f =3D f x) along with the required IO primitives. >> >> Regarding general utility functions, if they do not perform IO or depend >> on (blocking) IO they can be used directly with Async/Lwt (unless they >> really take a very long time to complete). >> >> Le Mon, 07 Mar 2016, Malcolm Matalka a =C3=A9crit : >> > Yotam Barnoy writes: >> > > Hi all >> > > >> > > I'm thinking about my next project in OCaml, and I'm wondering how >> many >> > > users of OCaml currently use Lwt or Async regularly. >> > > >> > > One of the advantages of OCaml over Haskell (which I'm not crazy >> about) is >> > > the fact that you don't have to constantly be stuck inside a monad. >> > > However, once you want to use these user-level threading libraries, >> you're >> > > essentially tied to a monad. It also means that the usage of any oth= er >> > > monad from Lwt/Async code is out -- OCaml doesn't have the monad >> > > transformer infrastructure to layer monads easily as far as I can >> tell (am >> > > I wrong?). I mean, even in Haskell using Monad Transformers is a pain >> (IMO). >> > > >> > > Also, what happens to general utility functions that aren't rewritten >> for >> > > Async/Lwt -- as far as I can tell, being in non-monadic code, they >> will >> > > always starve other threads, since they cannot yield to another >> Async/Lwt >> > > thread. Is this perception correct? If so, this seems to imply that >> you >> > > either write your code to cooperate within these frameworks and >> suffer the >> > > monad, or don't, and make it near-impossible for Lwt/Async users to >> make >> > > use of your code. >> > > >> > > I would like to get an idea of the usage level of these libraries, as >> well >> > > as the burden of writing compatible code, any difficulties etc. Also, >> I'd >> > > like to get a sense of the domains that benefit from these libraries. >> Some >> > > domains (such as gaming) traditionally involve a continuous main >> loop, and >> > > would thus only suffer from the additional overhead of queuing in >> these >> > > libraries. >> > > >> > > -Yotam >> > >> > I mostly use Async. However, I think most usage of Lwt or Async >> > requires doing as little as possible in these frameworks and using them >> > to orchestrate other functions. For example, I usually try to separate >> > parsing of a network protocol from the reading and writing of the byte= s. >> > >> > -- >> > Caml-list mailing list. Subscription management and archives: >> > https://sympa.inria.fr/sympa/arc/caml-list >> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> > Bug reports: http://caml.inria.fr/bin/caml-bugs >> >> >> -- >> Simon Cruanes >> >> http://weusepgp.info/ >> key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3 7D8D 4AC0 1D08 49AA >> 62B6 >> > > --001a11c1303256a2a5052d763e65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Also, what happ= ens to general utility functions that aren't rewritten for Async/Lwt --= as far as I can tell, being in non-monadic code, they will always starve o= ther threads, since they cannot yield to another Async/Lwt thread.
There is Lwt_pree= mptive.detach and Async's In_thread.run to get around this.
<= br>

> It seems that Lwt is more popular in= the community outside JaneStreet than Async (if only by looking at its rev= erse dependencies on opam.ocaml.org).= There has been posts about this, for instance http://rgrinberg.com/blog/2014/12/11= /abandoning-async/ .

I'd be wary of = drawing conclusions from one blog post and even from opam. I think the answ= er is: both are used a lot. Also depends on what you mean by "a user&q= uot;. It's not too useful to count Jane Street's packages and one b= arely used package on opam both as 1. A lot of code is not on opam.


>=C2=A0Is there an existing compatibility library functorized over the intersecti= on of Async and Lwt? That would make being compatible with both much easier= .

M= ost people provide this internally for each of their projects, e.g. Cohttp= 9;s IO signature. However, we have quite a few projects that needed thi= s abstraction, so duplicating this code in each repo seemed wrong. Thus we = developed future, which wa= s recently released in opam.



On Mon, Mar 7, 2016 at 9:06 AM, Yotam Barnoy <yotamb= arnoy@gmail.com> wrote:
Is there an existing compatibility library functorized over t= he intersection of Async and Lwt? That would make being compatible with bot= h much easier.

On Mon, Mar 7, 2016 at 4:08 AM, = Simon Cruanes <simon.cruanes.2007@m4x.org> wrote:
Hi,

It seems that Lwt is more popular in the community
outside JaneStreet than Async (if only by looking at its reverse
dependencies on opam.ocaml.org). There has been posts about this, for
instance http://rgrinberg.com/blog/2014/12/11/= abandoning-async/ .
However, if you're writing a library, it is good taste (if possible) to=
parametrize you code over an "IO" monad that will be easy to inst= antiate
with either Async or Lwt (or the trivial blocking monad where 'a t =3D = 'a
and (>>=3D) x f =3D f x) along with the required IO primitives.

Regarding general utility functions, if they do not perform IO or depend
on (blocking) IO they can be used directly with Async/Lwt (unless they
really take a very long time to complete).

Le Mon, 07 Mar 2016, Malcolm Matalka a =C3=A9crit :
> Yotam Barnoy <yotambarnoy@gmail.com> writes:
> > Hi all
> >
> > I'm thinking about my next project in OCaml, and I'm wond= ering how many
> > users of OCaml currently use Lwt or Async regularly.
> >
> > One of the advantages of OCaml over Haskell (which I'm not cr= azy about) is
> > the fact that you don't have to constantly be stuck inside a = monad.
> > However, once you want to use these user-level threading librarie= s, you're
> > essentially tied to a monad. It also means that the usage of any = other
> > monad from Lwt/Async code is out -- OCaml doesn't have the mo= nad
> > transformer infrastructure to layer monads easily as far as I can= tell (am
> > I wrong?). I mean, even in Haskell using Monad Transformers is a = pain (IMO).
> >
> > Also, what happens to general utility functions that aren't r= ewritten for
> > Async/Lwt -- as far as I can tell, being in non-monadic code, the= y will
> > always starve other threads, since they cannot yield to another A= sync/Lwt
> > thread. Is this perception correct? If so, this seems to imply th= at you
> > either write your code to cooperate within these frameworks and s= uffer the
> > monad, or don't, and make it near-impossible for Lwt/Async us= ers to make
> > use of your code.
> >
> > I would like to get an idea of the usage level of these libraries= , as well
> > as the burden of writing compatible code, any difficulties etc. A= lso, I'd
> > like to get a sense of the domains that benefit from these librar= ies. Some
> > domains (such as gaming) traditionally involve a continuous main = loop, and
> > would thus only suffer from the additional overhead of queuing in= these
> > libraries.
> >
> > -Yotam
>
> I mostly use Async.=C2=A0 However, I think most usage of Lwt or Async<= br> > requires doing as little as possible in these frameworks and using the= m
> to orchestrate other functions.=C2=A0 For example, I usually try to se= parate
> parsing of a network protocol from the reading and writing of the byte= s.
>
> --
> Caml-list mailing list.=C2=A0 Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group= /ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs


--
Simon Cruanes

http= ://weusepgp.info/
key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3=C2=A0 7D8D 4AC0 1D08 49A= A 62B6


--001a11c1303256a2a5052d763e65--