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 49EAE7FE53 for ; Wed, 9 Mar 2016 11:24:01 +0100 (CET) IronPort-PHdr: 9a23:TFxgXRU78SmvRbO3Sc8ejk74Bd7V8LGtZVwlr6E/grcLSJyIuqrYZhyGt8tkgFKBZ4jH8fUM07OQ6PC/Hzxeqs/Z+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8KVM1sD3WL1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHkOz4S45W2EdlR5NSy3M8Bj+XZ655i7/v/Z03CqTFcLzRLEwHz+l6vE4ZgXvjXIoOiQ1uFrLjchoiatdplr1phpxxKbbbZuZceFieafFeNocQyxNU5ACBGR6HoqgYt5XXKI6NuFCoty4/gNWoA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.17.24; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BbAABn+N9WkxgR49RchAxtulEBDYFpFwqFbgKBRzgUAQEBAQEBAQEQAQEBAQcNCQkhL4ItghUBAQQjMiQQCw4KKgICSQENBhMJiB8BCbAEjzQBAQEBAQEBAwEBAQEBARIIhR+FOoJagWuCPQstE4EnBYdcj1OBKgKEOYgMgWSHQgQjhS6OWh4BAYJWgVFpAYlSAQEB X-IPAS-Result: A0BbAABn+N9WkxgR49RchAxtulEBDYFpFwqFbgKBRzgUAQEBAQEBAQEQAQEBAQcNCQkhL4ItghUBAQQjMiQQCw4KKgICSQENBhMJiB8BCbAEjzQBAQEBAQEBAwEBAQEBARIIhR+FOoJagWuCPQstE4EnBYdcj1OBKgKEOYgMgWSHQgQjhS6OWh4BAYJWgVFpAYlSAQEB X-IronPort-AV: E=Sophos;i="5.24,311,1454972400"; d="asc'?scan'208";a="167788817" Received: from mout.kundenserver.de ([212.227.17.24]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2016 11:24:00 +0100 Received: from office1.lan.sumadev.de ([188.110.5.208]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MK4If-1acEEp0ch3-001Oho; Wed, 09 Mar 2016 11:23:54 +0100 Received: from [192.168.65.10] (unknown [192.168.65.10]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 01396DC05D; Wed, 9 Mar 2016 11:23:52 +0100 (CET) Message-ID: <1457519028.13223.20.camel@e130.lan.sumadev.de> From: Gerd Stolpmann To: Malcolm Matalka Cc: Jeremie Dimino , Yaron Minsky , Yotam Barnoy , Jesper Louis Andersen , Ocaml Mailing List Date: Wed, 09 Mar 2016 11:23:48 +0100 In-Reply-To: <86vb4w85o2.fsf@gmail.com> References: <86h9gi9msc.fsf@gmail.com> <86d1r69ho4.fsf@gmail.com> <868u1ta25r.fsf@gmail.com> <86vb4w85o2.fsf@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-tJoGhWHu/TyxxtmHcvY8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:lctoBmE+etEtcbxTvnTswrwsvxemH8kHGWvk2ntS/XaRVuXt4aS p/03Qnppq1sKWNUcRK0/y+bgTv2Hn0H/z8YHBl4gr7kuMYyxD2lJ9ewrKITQgjw0qVnIEEs Cm8d9gxHoLZHSNGCVLFMCLZLsdioZLaXggSj1hdS321RpQAoTYvpBYorzPmTUFQ2mcgqbP5 A2D8U8hXYTQPWt5hLYM0w== X-UI-Out-Filterresults: notjunk:1;V01:K0:FawjCS45kL4=:wnNMHvXZxKxENT+RyKNOBy obYCwKGck96GptOV0/19/YEuVbuOxrqKFuu6yHd7Mkg9CYlvWp7V+/D+s/VKQJnlpOu/EuzZD kVT7XDbZB8vWbvAh3+dU+QPqCM97p/tyrw4jvacGZaOoJrtuceL31AZB9qyaN1/TEEXb5oS4j 5ofHHCf51wMsOitsnTn2MCJJulQ1TWfZ8Wri6qBpF0wugzoCdr2KoixuEmeY/zJgpokM+5iXm zwa3PAfdGKvZ3ujsE+q9U6o0+pJP7lMDEv37zyqQcmyoPIDF0dfVaqX3Md6n3kDyWxi/pPjQ+ pb0HHNdFpd3KioXGJPgmFK28BFrnL5YUxBfw+txf9FoIH+yg2HmjgeefzU19qrFxbZ9bZ6Cqq bwNmMDenvU2fxJ5YOOIqkRsnZj13UeblpFyu2NIOr44c2e5oZzI07cEaDMIlNWnqW74tO+/cv T/gifV15xU9MfYqsdaFnLA2srVMFgq+MnI05TuMkK710zWbk5YTiCmSl2EEN41W5u3pd4ke9B Ba3YRanUhVGG0CRn0XoTqkmWGYAoGjscELeMzfrzhAmmd4s1EwpC5cJ5rI/zXRGJYgtEL8PNU JNp6BkMHs/WGGvfTPYTitDFc0vizDI56OK0xan5AJTqP0tCJx2rJPW/7S/JjKecdR7rl/urLZ G7k1c4lW+QIV+YtHtqym8QiG1wk0m0MLUyEwMfM+4FvHUf1AmDEu4E0yg4SHFqbkxW8g= Subject: Re: [Caml-list] Question about Lwt/Async --=-tJoGhWHu/TyxxtmHcvY8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Am Mittwoch, den 09.03.2016, 07:35 +0000 schrieb Malcolm Matalka: > Jeremie Dimino writes: >=20 > > On Tue, Mar 8, 2016 at 12:47 PM, Yaron Minsky > > wrote: > > > >> Jeremie, other than having some different back-ends available (e.g., g= lib > >> main loop), how different are the approaches to backend management bet= ween > >> Async and Lwt? > >> > > > > =E2=80=8BThe backend interfaces are slightly different=E2=80=8B, but we= just need a bit of > > glue in the middle. Essentially the difference is that with Lwt you pro= vide > > one callback per fd and watch (read or write), while with Async you hav= e 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 c= an only > > choose between the predefined epoll and select ones > > - make the scheduler ignore fds returned by the backend that are not > > handled by async >=20 > 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). >=20 > The work in progress around the interface can be found below, any > constructive feedback would be appreciated. >=20 > https://bitbucket.org/acslab/abb_scheduler_inf/src >=20 Very academic. The reality is different. Most of these operations are only provided as synchronous calls anyway in all OS I know (and you can only provide a non-blocking version by using helper threads). The only operations you can do something about are those reading/writing a file descriptor, but even here there is a strong OS dependency, e.g. on Windows async operations are very restricted, limiting implementation options drastically. The truth is that you cannot abstract the OS away. And what if I need linkat and not link? And what about calling my favorite C library that uses blocking I/O? E.g. I'm often preferring a variant of Unix.read/write using bigarrays as buffer. I'd prefer a reduced approach for interoperability: Focus on event loops and ways to read/write, and accept that everything else must be dealt with using helper threads. Sorry for not being constructive. I don't like the approach (and I also don't like Lwt and Async, and by the way these are not the only kids on the block). Gerd --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-tJoGhWHu/TyxxtmHcvY8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJW3/m0AAoJEAaM4b9ZLB5TagYH/3rWw8i3eJfBS4+f7hb3z6SQ 5cXzDrUGFiX89YaeUh5iHpCuZp+mNEx/ZWdDcOjbTlt2ye19ZPW6OD39XY/g57uO H6BRqA8z/PCJnJDVQyTZnaeiKjkdnYC47evPXV5fCRrBYez9dPuKqgVXNPBoWqB7 /m3+j/buZ3Isfq1/7JIX95uMzNBda4GwjFDMV+H/Qf2VNU5EyZJXhgAzi0pKi86J Ugppag7mObbVXn0jyYFOnmzZdYA0d1nxeGDiPlnksynZ7Nl8I1YbwRaSLdtH/NJU 1Zqw16C7bRpVIrgm20Vj6MMcZ2E9LOGe6AzUlNj3/PXjB75b1aSH1VU8UUwf7Xw= =0I92 -----END PGP SIGNATURE----- --=-tJoGhWHu/TyxxtmHcvY8--