From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Allan Webber Newsgroups: gmane.lisp.guile.devel Subject: Re: Asynchronous event loop brainstorm at FSF 30 Date: Sun, 04 Oct 2015 10:19:03 -0500 Message-ID: <87eghau05r.fsf@dustycloud.org> References: <87k2r3tvzh.fsf@dustycloud.org> <6256857ed9f289c87b0deafd17bc8eb9@hypermove.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443972276 29290 80.91.229.3 (4 Oct 2015 15:24:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 15:24:36 +0000 (UTC) Cc: guile-devel-bounces+amirouche+dev=hypermove.net@gnu.org, guile-devel@gnu.org To: Amirouche Boubekki Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Oct 04 17:24:35 2015 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zil9P-0008FE-7v for guile-devel@m.gmane.org; Sun, 04 Oct 2015 17:24:35 +0200 Original-Received: from localhost ([::1]:42851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zil9O-00041E-KX for guile-devel@m.gmane.org; Sun, 04 Oct 2015 11:24:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zil9K-000417-NQ for guile-devel@gnu.org; Sun, 04 Oct 2015 11:24:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zil9J-0001VH-OV for guile-devel@gnu.org; Sun, 04 Oct 2015 11:24:30 -0400 Original-Received: from dustycloud.org ([2600:3c02::f03c:91ff:feae:cb51]:37201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zil9J-0001V9-JW for guile-devel@gnu.org; Sun, 04 Oct 2015 11:24:29 -0400 Original-Received: from earlgrey (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id BBB44228645; Sun, 4 Oct 2015 11:24:27 -0400 (EDT) In-reply-to: <6256857ed9f289c87b0deafd17bc8eb9@hypermove.net> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c02::f03c:91ff:feae:cb51 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17894 Archived-At: Amirouche Boubekki writes: > H=C3=A9llo, > > Please excuse my layman question in advance. > > I find the idea awesome to work on asynchronous framework for Guile. > > Le 2015-10-04 00:29, Christopher Allan Webber a =C3=A9crit: >> So David Thompson, Mark Weaver, Andrew Engelbrecht and I sat down to >> talk over how we might go about an asynchronous event loop in Guile=20 >> that >> might be fairly extensible. Here are some of what we discussed, in >> bullet points: >>=20 >> - General idea is to do something coroutine based. > > IUC coroutine takes advantage of the ability to pause the execution of=20 > given procedure A to run a blocking operation B and execute some other=20 > procedure C while the blocking operation B is running. At some point,=20 > when the blocking operation B is finished, and C is finished, A restart= s=20 > where it left. Sort of, I'm not sure that "blocking" needs to be tossed in there. We're interested in as much nonblocking behavior as possible. Coroutines in this case basically means functions that can be suspended and then woken up again when whatever asynchronous code they rely on has completed (possibly receiving a value from that as well). >> - This would be like asyncio or node.js, asynchronous but *not* OS >> thread based (it's too much work to make much of Guile fit around >> that for now) >>=20 >> - If you really need to maximize your multiple cores, you can do >> multiple processes with message passing anyway > > Does it mean that there will be one event loop per thread per process ? Yes. >>=20 >> - So what we really need is a nice API for how to do coroutines, writ= e >> asynchronous code, and work with some event loop with a scheduler > > >> - Probably a good way to start on this would be to use libuv (or is i= t >> libev?) and prototype this. It's not clear if that's a good long >> term approach (eg, I think it doesn't work on the HURD for those wh= o >> care about that, and Guix certainly does) > > In asyncio the event loop can be swapped the default event loop is pure= =20 > python. You mean that the first version will use libuv (libuv is the=20 > nodejs eventloop, formely based on libev). Right, I think that modeling the event loop in an abstract way is a strong idea. One nice feature is that the asyncio event loop can be swapped out... thus, it's possible to use the default event loop, a GTK event loop, or twisted, or whatever, IIRC >> - Binary/custom ports could be a nice means of abstraction for this >>=20 >> So, that's our thoughts, maybe someone or one of us or maybe even *you= * >> will be inspired to start from here? >>=20 > > I don't want to make promises (pun on punpose) but I find this proposal= =20 > really interesting. Great! And good pun :)