From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: Asynchronous event loop brainstorm at FSF 30 Date: Sun, 04 Oct 2015 23:58:21 +0800 Organization: HFG Message-ID: <1443974301.7787.40.camel@Renee-desktop.suse> References: <87k2r3tvzh.fsf@dustycloud.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1443974329 26535 80.91.229.3 (4 Oct 2015 15:58:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 Oct 2015 15:58:49 +0000 (UTC) Cc: guile-devel@gnu.org To: Christopher Allan Webber Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Oct 04 17:58:48 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 1ZilgV-000456-Qu for guile-devel@m.gmane.org; Sun, 04 Oct 2015 17:58:47 +0200 Original-Received: from localhost ([::1]:42930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZilgV-00026a-6Q for guile-devel@m.gmane.org; Sun, 04 Oct 2015 11:58:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZilgS-00026Q-F9 for guile-devel@gnu.org; Sun, 04 Oct 2015 11:58:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZilgJ-0000Vo-J3 for guile-devel@gnu.org; Sun, 04 Oct 2015 11:58:44 -0400 Original-Received: from mail-pa0-x236.google.com ([2607:f8b0:400e:c03::236]:33015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZilgJ-0000Vk-Db for guile-devel@gnu.org; Sun, 04 Oct 2015 11:58:35 -0400 Original-Received: by pacex6 with SMTP id ex6so151897450pac.0 for ; Sun, 04 Oct 2015 08:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :organization:content-type:mime-version:content-transfer-encoding; bh=MCG/shKQ44f3bv7diMKqSvqru6poVLPzj/TM9cUAGFM=; b=DqFpOlyILTIQgV9g4ehE99qwtnIq6q4TGkX3QR8axGox9FS1kl/2GPv2Rzf85wJwJx UY6Dy3IP1sKYSeDdLVPBK7Qfhf6pWfDjx46Yl0IKBL0KUmDVqptL30RmJ/la1YaqVpHf TEcuJwsOsrdl2K4cHcvLeHfWLp1RocIq/GQbnRmNDxGuZVpGPqGLvbpD/ooih2emqfTw 6Pa+Ldb6byngdgCRXDg6rhEuqdjqz6Z+P72+fQprAu0EqJrFuyQ+EVxRDe3ninBc0Tqq gQuBjHGfSR4ur+KpnTok5Jcbj30AV5KB5lSu3cTje6/1UTATrE9Y9WG2TWs8hr8FPKd3 NZQg== X-Received: by 10.68.57.143 with SMTP id i15mr34318188pbq.104.1443974314483; Sun, 04 Oct 2015 08:58:34 -0700 (PDT) Original-Received: from [127.0.0.1] (li88-185.members.linode.com. [74.207.246.185]) by smtp.gmail.com with ESMTPSA id gi4sm22724630pbc.4.2015.10.04.08.58.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Oct 2015 08:58:33 -0700 (PDT) In-Reply-To: <87k2r3tvzh.fsf@dustycloud.org> X-Mailer: Evolution 3.4.4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::236 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:17896 Archived-At: Hi Christopher! I'm one of guys who's interested in this topic, say, async IO in Guile. On Sat, 2015-10-03 at 17:29 -0500, Christopher Allan Webber wrote: > - 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) Personally, I would like to avoid callback way for asyncio which is the way in node.js. And I believe we have chances to avoid it in Guile. > - If you really need to maximize your multiple cores, you can do > multiple processes with message passing anyway I've learned roughly about how Erlang deals with multicore problem (I don't know if Erlang has better solution since 2008). I'm not going to discuss about the design here, but I have to mention that a proper general coroutine interface in Guile core should provide a flexible way to let users do there scheduling policy with multicores. Maybe it's too idealism, but it's no harm to list it before the coding work. > - Initially, this would probably providing a general API for > coroutines. Mark thinks delimited continuations would not be as > efficient as he'd like, but we think it's okay because we could > provide a nice abstraction where maybe something nicer could be > swapped out later, so delimited continuations could at least be a > starting point. Yes the current delimited-continuations is not so efficient. I think it has to be optimized in the future. But I'm still standing on optimistic side of delimited-continuation based asyncio design. Yes, I know it's faster (in single core) if we use libev/libuv, which keeps fewer information/states for each request compared to continuations. But I don't see it's the best solution for scalability taking advantage of distributed system. Maybe I'm a little out of topic, a general async event loop is unnecessary to be salable. > - So what we really need is a nice API for how to do coroutines, write > asynchronous code, and work with some event loop with a scheduler > > - On top of this, "fancier" high level systems like an actor model or > something like Sly's functional reactive programming system could be > done. Yes, it's better than playing raw continuations, which is hard to handle and debug. ;-) > - Probably a good way to start on this would be to use libuv (or is it > 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 who > care about that, and Guix certainly does) Anyway, it's no harm to add an implementation based on libuv/libev, but I think it's improper to be put in Guile core. Or we'll introduce third party lib as the prerequisites. Unfortunately, there's no epoll in GNU/Hurd although it is believed not so hard to be added based on current `select' in Glibc (different from Linux, these stuffs are in userland on Hurd). I have discussed it with Hurd folks, but we still have no coding work for it yet. Again, it's no harm to add it as a lib, folks need efficient asyncio, always. > - Binary/custom ports could be a nice means of abstraction for this Years ago, Mark Weave has told me (actually it's a kindly warning) that we have to handle the ports properly for nonblock asyncio. It could be more complex if one uses DB in her/his program. It's better if we could have better abstraction for these ports. But I still have no idea about it. Any more comments? I think it's better to discuss it more, and list more potential issues to be noticed。There're always big problems when you want to design general interface.