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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 42D127FF9F for ; Mon, 7 Mar 2016 16:05:40 +0100 (CET) IronPort-PHdr: 9a23:hytDqx114DgrvdIlsmDT+DRfVm0co7zxezQtwd8ZsegRIvad9pjvdHbS+e9qxAeQG96LtLQU0qGI4+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6NyZTunL7is7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjMD39DwrRTIUSeI43IdVC1WzksJUED560TgQ5vw9CTgt+x31TOVFcLzRLEwHz+l6vRFUhjt3QYZPjhx32bLjdJ7jKNHu1r1pgJw64/ZbYzTM+BxKPCONegGTHZMC54CHxdKBZmxOs5SVuc= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lb0-f177.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.217.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ivg@ieee.org designates 209.85.217.177 as permitted sender) identity=mailfrom; client-ip=209.85.217.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lb0-f177.google.com) identity=helo; client-ip=209.85.217.177; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lb0-f177.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQB5l91WlbHZVdFdgm6BHm0GqgsqkBOBaSOFbAKBIgc6EgEBAQEBAQEBEAEBAQEHCwsJIS+CLYIUAQEBAwESER0BASwLAQQLCwsNDR0CAiEBEgEFAQoSGQgKAg6HawMKCA6iRYExPjGKT2eEQQEEhWEDCoRHAQEBAQEBBAEBAQEBAQEBAQEBDwYKhg2EPYI9gUxeglOBOoYhDId8iQaFY4YVgXWCLoxMhwyGCxEegQ8PGA2CJAoUCIFmHi4BiTwBAQE X-IPAS-Result: A0D3AQB5l91WlbHZVdFdgm6BHm0GqgsqkBOBaSOFbAKBIgc6EgEBAQEBAQEBEAEBAQEHCwsJIS+CLYIUAQEBAwESER0BASwLAQQLCwsNDR0CAiEBEgEFAQoSGQgKAg6HawMKCA6iRYExPjGKT2eEQQEEhWEDCoRHAQEBAQEBBAEBAQEBAQEBAQEBDwYKhg2EPYI9gUxeglOBOoYhDId8iQaFY4YVgXWCLoxMhwyGCxEegQ8PGA2CJAoUCIFmHi4BiTwBAQE X-IronPort-AV: E=Sophos;i="5.22,551,1449529200"; d="scan'208,217";a="206395959" Received: from mail-lb0-f177.google.com ([209.85.217.177]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 07 Mar 2016 16:05:38 +0100 Received: by mail-lb0-f177.google.com with SMTP id bc4so133300324lbc.2 for ; Mon, 07 Mar 2016 07:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=qcPl9WBmYg94wWE7HT/L7P0jnMjU26vAWYq0UYKbuVY=; b=ghj6H1rmQ3lYB9uWXPuDS8gykFRdTXCEKX/BjLdVWrmFzpRU8HuOr5D8o9L5zsD46O v6PvoCkH31HxuAiAG3536ZPsb/N6RyzvMNqTa888wtLbxPu+so9xp1YedylbzChtYva5 7oUMXsfLviOth3gCsAy4o46eYDn2yGxevJB6p5k2LTrQFjLjMTui5OPAQLPF5NregOGV Yw5dcp6I3bjz9VkLYWKzoNasCrcAtAKdb2ZY31odF/RK3oMtlZSL0hLoa2i/voDMl5s6 UKO1gSW+S7aSSybVd1o7pq4aW5WP5fFX1EWNuHEuRlC5fcfekSQ9s7oapNpasFGb3P4q rgrQ== 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:date :message-id:subject:from:to:cc; bh=qcPl9WBmYg94wWE7HT/L7P0jnMjU26vAWYq0UYKbuVY=; b=mwxLORnTC5r5POaiEvcRyweiCfBndYT2iWaB/oI69KMpyn602TkcHh6wruq3tb9jfT gdNel7It7MHEJmydqWsZo1DICY5Fug0kg3spyjJSweLT4gKd+Fgy5Lu7Xt9pPPzEGt6B GGOiI9C+LepBNeCysZYp34ZeVZZtMaBDnIiwD/HwDn7i5pBwSVZnMWB6N8VRRdUd1Kdz Bae0nf80TaZ3L/dAdvTTwXyqvmZieHV81oWF0/+KPaOqO96PbHjt9xvA/Sw2jMeo2ADn Aic6soPeKotI4ryMSUfKMFUFp5KV4siOCaKFmDP+kKA3Xwj+hjEMkuvSF6TG3WK1MM+R Zrzg== X-Gm-Message-State: AD7BkJJrATAmIthEFgW+vdPBL+r+JCseBXLAqtoU0I09Gv54tbzdQtk0K77peXufM9gi2qngeBoClzEkRsON/QAM MIME-Version: 1.0 X-Received: by 10.112.132.65 with SMTP id os1mr2268414lbb.118.1457363138001; Mon, 07 Mar 2016 07:05:38 -0800 (PST) Received: by 10.114.180.161 with HTTP; Mon, 7 Mar 2016 07:05:37 -0800 (PST) In-Reply-To: References: <86oaaqahc1.fsf@gmail.com> <20160307090859.GF30630@nunchakus.loria.fr> Date: Mon, 7 Mar 2016 10:05:37 -0500 Message-ID: From: Ivan Gotovchits To: rudi.grinberg@gmail.com Cc: Ashish Agarwal , Yotam Barnoy , Simon Cruanes , Malcolm Matalka , Ocaml Mailing List Content-Type: multipart/alternative; boundary=047d7b3a81c42667b8052d76cc3a Subject: Re: [Caml-list] Question about Lwt/Async --047d7b3a81c42667b8052d76cc3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We actually have another work, that heavily intersects with `Lwt` and `Async`. It is code named `bap-future`[1], and in short this is a library to work with asynchronous values. This can be seen, as `Lwt.t` or `Ivar.t` cleaned up of everything unnecessary. In the ideal future, the `Future.t` can be used as a common denominator between `Lwt` and `Async`. [1]: https://github.com/BinaryAnalysisPlatform/bap/blob/master/lib/bap_future/ba= p_future.mli P.S. It will be also released very soon. On Mon, Mar 7, 2016 at 9:59 AM, Ivan Gotovchits wrote: > > While I still prefer Async=E2=80=99s interface > > Me too, that's why we created an [overlay][1] over Lwt, that provides an > interface in the style of Core library. > I'm currently working on releasing this library to opam. > > [1]: https://github.com/BinaryAnalysisPlatform/core-lwt > > On Mon, Mar 7, 2016 at 9:55 AM, wrote: > >> Since my post was mentioned, I thought I=E2=80=99d chime in. >> >> I=E2=80=99ve used both libraries and I=E2=80=99ve found little practical= difference >> between the two. I think porting a codebase from Lwt to Async (and vice >> versa) is mostly mechanical work. >> >> While I still prefer Async=E2=80=99s interface a little more but I think= the two >> main points in my blog post still stand. If portability and maximum >> interoperability with the community are important to you then the decisi= on >> is already made in my eyes. >> >> On March 7, 2016 at 9:26:41 AM, Ashish Agarwal (agarwal1975@gmail.com) >> wrote: >> >> > 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 w= ill >> 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.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 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. Coh= ttp'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 bo= th >>> 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 instantia= te >>>> 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 depe= nd >>>> 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 >>>> other >>>> > > 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 >>>> bytes. >>>> > >>>> > -- >>>> > 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 >>>> >>> >>> >> > --047d7b3a81c42667b8052d76cc3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We actually have another work, that heavily intersects wit= h =C2=A0`Lwt` and `Async`. It is code named `bap-future`[1], and in short t= his
is a library to work with asynchronous values. This can be seen, as= `Lwt.t` or `Ivar.t` cleaned up of everything unnecessary.=C2=A0
= In the ideal future, the `Future.t` can be used as a common denominator bet= ween `Lwt` and `Async`.=C2=A0


P.S.=C2=A0It will = be also released very soon.=C2=A0
On Mon, Mar 7, 2016 at 9:59 AM, Ivan Gotovchits= <iv= g@ieee.org> wrote:
> While I still prefer Async=E2=80=99s in= terface

Me too, that's why we creat= ed an [overlay][1] over Lwt, that provides an interface in the style of Cor= e library.=C2=A0
I'm currently working on releasing this libr= ary to opam.


On Mon,= Mar 7, 2016 at 9:55 AM, <rudi.grinberg@gmail.com> wr= ote:
=
Since my post was mentioned, I thought I= =E2=80=99d chime in.

I=E2=80=99ve used both libraries and I=E2=80=99v= e found little practical difference between the two. I think porting a code= base from Lwt to Async (and vice versa) is mostly mechanical work.

Wh= ile I still prefer Async=E2=80=99s interface a little more but I think the = two main points in my blog post still stand. If portability and maximum int= eroperability with the community are important to you then the decision is = already made in my eyes.

On March 7, 201= 6 at 9:26:41 AM, Ashish Agarwal (agarwal1975@gmail.com) wrote:

>=C2=A0Also, 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.oc= aml.org). There has been posts about this, for instance http://rgrinberg.com/blog/2014/12/11/aba= ndoning-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 Ja= ne Street's packages and one barely 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 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 <yotambarnoy@gmail.com> 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 <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 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 <yotambarnoy@gmail.com> 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 other
> > 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.=C2=A0 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.=C2=A0 For example, I usually try to separate
> parsing of a network protocol from the reading and writing of the bytes.
>
> --
> 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 49AA 62B6




--047d7b3a81c42667b8052d76cc3a--