From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: Re: Guile fibers return values Date: Mon, 6 Jan 2020 20:42:17 +0100 Message-ID: <7661b27f-787e-fc8f-d653-5fbabffa01f7@posteo.de> References: <20200105123329.5019662bdf1895a4164faf62@gmail.com> <20200105142358.4ad96d15a23a0b947b2d55e3@gmail.com> <547672e4-30f7-2783-f3d5-199417a71c98@posteo.de> <20200105214555.60e424b8cf86456e188c75f6@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="258678"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 Cc: Guile User To: Chris Vine Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jan 06 20:42:45 2020 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ioYGy-0015Bw-SL for guile-user@m.gmane.org; Mon, 06 Jan 2020 20:42:45 +0100 Original-Received: from localhost ([::1]:59212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioYGx-0006Ft-L1 for guile-user@m.gmane.org; Mon, 06 Jan 2020 14:42:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51601) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ioYGe-0006FU-Qu for guile-user@gnu.org; Mon, 06 Jan 2020 14:42:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ioYGb-000717-NZ for guile-user@gnu.org; Mon, 06 Jan 2020 14:42:24 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:40135) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ioYGb-0006xX-50 for guile-user@gnu.org; Mon, 06 Jan 2020 14:42:21 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id B342E240101 for ; Mon, 6 Jan 2020 20:42:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1578339738; bh=ZvRjp343BpdRMsF5loGrli29tIMSQ2J8axXLqRt0IGM=; h=Subject:To:Cc:From:Date:From; b=YxWSfscH0p5nMnoQBkEISyjZJsj4NtiXgary2zNGYNcoaYYtJS3JC5LhewGgy8pYU wFyqKcb3rV0U0R6AZCP/tDSLiFDIXjETig+4EswxnlOdmu0zSp/qGvqzha+ToWSsJS ty7EjllcxytQuW06H3GBYt7gmE0/fx1QupC1MgLt/DmXFQKs8QH37CdCPp9TznbRDm +iSOFrREpetZa+6MV32ke+0P5lwKFRdZpQB1dhiPzIHF2OJgW9CBGRiNceUgPVtpHb WRRXMzkNTFAQnEUOwFoVPKnMb5giG4rnQQ4kRdBl6nyVNvbHY3BR5rgwW0j5p6lJKj JOCpFxT6iVXmQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 47s5WG0CsVz9rxB; Mon, 6 Jan 2020 20:42:17 +0100 (CET) In-Reply-To: <20200105214555.60e424b8cf86456e188c75f6@gmail.com> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 185.67.36.66 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15999 Archived-At: Hey Chris! Thanks for your informative reply! I did not remember, that the parallel forms are already that clever. It might be the case, that I only need to use futures or parallel forms then. I have a question regarding futures though. In Racket the futures have some limitations, where one needs to use a different number type to enable them in some cases to run in parallel =E2= =80=93 wait, I am looking for the link =E2=80=A6 here: https://docs.racket-lang.org/guide/parallelism.html =E2=80=93 Is there an= y similar restriction for futures in Guile? Regards, Zelphir On 1/5/20 10:45 PM, Chris Vine wrote: > On Sun, 5 Jan 2020 19:22:14 +0100 > Zelphir Kaltstahl wrote: >> I think the decision tree calculations, which I want to parallelize, a= re >> not I/O related. However, I am not quite sure I understand the whole >> suspendable port thing, but here is what I think it is: >> >> When some I/O happens in a fiber, the fiber is still able to pause >> (suspend, yield, =E2=80=A6) at that point, because the suspendable por= ts work in >> such a way, that no harm is done in doing so. Later the I/O work can b= e >> resumed (woken up from suspension). This quality had to be built into >> Guile first, before fibers were able to take advantage of it. >> >> Is this correct? > Yes, suspendable ports were first implemented in guile-2.2. They are > used by 8-sync (https://www.gnu.org/software/8sync/), guile-a-sync2 > (https://github.com/ChrisVine/guile-a-sync2/wiki) and fibers, and > possibly by other libraries. > > The basic arrangement is that if a port's file descriptor is not ready, > then its continuation is saved, and is resumed by the scheduler when it > becomes ready. fibers use epoll rather than POSIX select or poll for > this. > >> But I do not understand, why this is not the case with normal OS >> threads. Maybe it can be done but is not convenient or difficult to ge= t >> right, to work with suspendable ports, when not using the fibers libra= ry? >> >> And why is simple-format not "suspendable-port-safe"? (What does a >> procedure need to do, in order to be "suspendable-port-safe"?) > simple-format does not suspend as it is implemented in C in libguile an= d > its continuation is not available to scheme code. There is a > list of those of guile's i/o procedures which do (and which do not) > suspend here, in the second and third paragraphs, although it does not > mention format/simple-format: > https://github.com/ChrisVine/guile-a-sync2/wiki/await-ports > (That library has nothing to do with fibers, but as mentioned above it > happens to use suspendable ports for similar purposes):=20 > > None of this is likely to be relevant to your use case. > > [snip] >> With the parallel forms, isn't it the case, that at each call of such = a >> form, new OS threads are created? In this case it might be a good idea >> to create a fibers scheduler and reuse it, if that is possible, so tha= t >> I do not need to create my own process pool kind of thingy. > guile's parallel forms are implemented using futures, which use an > internal thread pool according to this: > https://www.gnu.org/software/guile/docs/master/guile.html/Futures.html#= Futures > > "Internally, a fixed-size pool of threads is used to evaluate futures, > such that offloading the evaluation of an expression to another thread > doesn=E2=80=99t incur thread creation costs. By default, the pool conta= ins one > thread per available CPU core, minus one, to account for the main > thread." > > Chris