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 CE8CB7FE53 for ; Wed, 9 Mar 2016 08:36:10 +0100 (CET) IronPort-PHdr: 9a23:v9QWURYlze4Bu3+L1FvBA1v/LSx+4OfEezUN459isYplN5qZpcS5bnLW6fgltlLVR4KTs6sC0LqJ9fC9EjVYsd6oizMrTt9lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUiv2OQc9HOnpAIma153xjLDtvc2OKFwQ1HKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQBTeIs1kRSGgTkxcALwnA7Rf9FsPzvir/t+x68CuTO8DtUao5VCjk5KBuHkzGkiACYhsw9GrQjsk4qatHqRairlQrxovdfIiRN/NWcabUfNdcTm1ECJUCHxddC5+xOtNcR9EKOvxV+syk/wMD Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=mmatalka@gmail.com; spf=Pass smtp.mailfrom=mmatalka@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-f43.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=74.125.82.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mmatalka@gmail.com designates 74.125.82.43 as permitted sender) identity=mailfrom; client-ip=74.125.82.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; 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-wm0-f43.google.com) identity=helo; client-ip=74.125.82.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-wm0-f43.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BpAAAy0d9WkitSfUpchAxtsASKYwENgWkhhW4CgUQ4FAEBAQEBAQEBEAEBAQEHCwsJIS+CLYIUAQEBAwESER0BGx0BAwELBgULAwoCAgUhAgIPAQQPEQEFAQ4BExMih2wBAwoIBAqiGoExPjGLNoFqgleFTgoZJw1Rg3gBAQEBAQEBAwEBAQEBAQEBAREBAQQKBG2DF4IFhEKCWoFegwKBOgWXL4VliAyBZIc4MYUujRwvgQ8eAQGCOB6BUGqJUwEBAQ X-IPAS-Result: A0BpAAAy0d9WkitSfUpchAxtsASKYwENgWkhhW4CgUQ4FAEBAQEBAQEBEAEBAQEHCwsJIS+CLYIUAQEBAwESER0BGx0BAwELBgULAwoCAgUhAgIPAQQPEQEFAQ4BExMih2wBAwoIBAqiGoExPjGLNoFqgleFTgoZJw1Rg3gBAQEBAQEBAwEBAQEBAQEBAREBAQQKBG2DF4IFhEKCWoFegwKBOgWXL4VliAyBZIc4MYUujRwvgQ8eAQGCOB6BUGqJUwEBAQ X-IronPort-AV: E=Sophos;i="5.24,310,1454972400"; d="scan'208";a="206735860" Received: from mail-wm0-f43.google.com ([74.125.82.43]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 09 Mar 2016 08:36:10 +0100 Received: by mail-wm0-f43.google.com with SMTP id p65so180091672wmp.1 for ; Tue, 08 Mar 2016 23:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=jGB9tJRJ6JJ6r/2B2mE5DBLRLXUbOXu8CHOl82Xe88s=; b=Nv+IOn/j+uSMWsXMHu5YG/f4/aJRuLnNsPEpJTm+VpBscw5XgNQWp/gqO07f1FesoK URzHjR6xwh/0SV83syDQqybZUcFOmvjj3JeO5M2nThBnD7jzUICndN1qsW/M5edTvbn2 ldY59zQ9nnDYp+DfI8u/O6JhZzpcoVnrkFAtwIonUb/u+lvrLvZ8+8boT4CYKU6kjGyN qtj9dEg2LPGWuhmdgvUXVNkLuUH5y4vUT04sd+vEMMpmXJK36KRs6zHDKyw1Q9dD3ZMJ GqB6EGIp9oQmFLTh/ajd37QAkkldzrUb43+H2AfLx1IhCxxKmvOPfnrFjK0VGl/b7ymU RsjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=jGB9tJRJ6JJ6r/2B2mE5DBLRLXUbOXu8CHOl82Xe88s=; b=g7DeaoMMtYzgUG0KBmTf1ngyqOB0a4WREpbZl5J96BklSddEFkd/VBZaISskOm37ed SZZKZn/1NVLdoZZ5JKFNAPuoj+ItIkXcR3g7oX1n5R9UgUu69kmliaFeAVOdFnHkJQ6K 7dwIsMltkQoDcw6FOJJiHnATdWb+4rJkcTbc8/6vCkY1P2mB0OSK3kfKfA5eHwxsRLRv DqN7vAwWRXJFURh/DIpEHhcLIE+A/NqwQucfaBVTnRJHjRIxbwzM+2ybeei+/PTvQH0l a0rUhVvAfm1/jdHJ1l4AorzenDxgiml+5nskmjrC7TmPnU8aR4EJjYeUZ2QYs5X9XLtM mw2A== X-Gm-Message-State: AD7BkJKh7/noQ6QY2ErA7RHqh+LO+3jbx1PJf9TEwcS0/oFwda77DiWk7Jn2KqJS9VWZhw== X-Received: by 10.194.123.102 with SMTP id lz6mr36845330wjb.2.1457508970153; Tue, 08 Mar 2016 23:36:10 -0800 (PST) Received: from localhost ([37.153.108.22]) by smtp.gmail.com with ESMTPSA id k124sm6895878wmb.11.2016.03.08.23.36.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Mar 2016 23:36:09 -0800 (PST) From: Malcolm Matalka To: Jeremie Dimino Cc: Yaron Minsky , Yotam Barnoy , Jesper Louis Andersen , Ocaml Mailing List References: <86h9gi9msc.fsf@gmail.com> <86d1r69ho4.fsf@gmail.com> <868u1ta25r.fsf@gmail.com> Date: Wed, 09 Mar 2016 07:35:41 +0000 In-Reply-To: (Jeremie Dimino's message of "Tue, 8 Mar 2016 13:03:51 +0000") Message-ID: <86vb4w85o2.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Question about Lwt/Async Jeremie Dimino writes: > On Tue, Mar 8, 2016 at 12:47 PM, Yaron Minsky > wrote: > >> Jeremie, other than having some different back-ends available (e.g., glib >> main loop), how different are the approaches to backend management betwe= en >> Async and Lwt? >> > > =E2=80=8BThe backend interfaces are slightly different=E2=80=8B, but we j= ust need a bit of > glue in the middle. Essentially the difference is that with Lwt you provi= de > one callback per fd and watch (read or write), while with Async you have a > global callback. > > =E2=80=8BRight now what we need to change in Async to make this work is: > > - allow to provide a backend =E2=80=8Bprogrammatically; right now you can= only > choose between the predefined epoll and select ones > - make the scheduler ignore fds returned by the backend that are not > handled by async For what it's worth, which isn't much right now, I've been slowly developing an interface point for event loops and user facing code. The rough idea is to present "asynchronous system calls" like an OS would, so user facing code has an interface to program against and the underlying event loop can change as someone wants, libev, libuv, direct epoll or kqueue, etc. So Async and Lwt libraries could be implemented in terms of this interface and share the same event loop, to cooperate nicely. So far I haven't implemented anything using the interface except for a barely functional test to demonstrate that it even works, so it's quite raw. And it's clearly deficient on a few things, but I think the idea is sound and would alleviate some of the pain of deciding to use Lwt or Async and if it works on JS or Windows or My Favorite OS (just flip out the underlying scheduler implementation). The work in progress around the interface can be found below, any constructive feedback would be appreciated. https://bitbucket.org/acslab/abb_scheduler_inf/src