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: Sun, 5 Jan 2020 13:58:24 +0100 Message-ID: References: <20200105123329.5019662bdf1895a4164faf62@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="15340"; 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@gnu.org To: Chris Vine Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 05 14:07:56 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 1io5dM-0003qr-6J for guile-user@m.gmane.org; Sun, 05 Jan 2020 14:07:56 +0100 Original-Received: from localhost ([::1]:41940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1io5dK-00042I-KO for guile-user@m.gmane.org; Sun, 05 Jan 2020 08:07:54 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58247) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1io5UE-0001qd-TM for guile-user@gnu.org; Sun, 05 Jan 2020 07:58:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1io5UD-0004HA-Cr for guile-user@gnu.org; Sun, 05 Jan 2020 07:58:30 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:59720) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1io5UC-0004Bo-Pd for guile-user@gnu.org; Sun, 05 Jan 2020 07:58:29 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 0C4E0160063 for ; Sun, 5 Jan 2020 13:58:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1578229107; bh=fJ7aNFegGTFlyFScONNzAqU8hVlIAexhNBs9xcnthZc=; h=Subject:To:From:Cc:Date:From; b=iNg9w0ICLKtKWlDbktJi+d3knT0Bd1LY7pofelnb63ZysOKLRau2v+VbJPvXLd/t9 1A1VM1syfMWxlAZ5nCCwwUpn+yI+L+Xzu1eK1oMLVvohaKAcOxJBw5KBraan/9ZvaL gtW1z1fFlBzjxnl0rBIXVyon6uOvsfPS7jR2/BPOGtQV/4S3nuM8re1NA7ppeB7CB5 t4gcl5vppkV+vv8QcTZ+B+eqHx03fbcuG0wPWKqOdOdLvEIc8LOfSKT+Wrmm9cxBNg eoVM1T8Fwv5Gw5tObTqniqxKppVJz/VyAsilIxljWr/0UDnm64rOU/gl3Jkahp7DQD aJEMXZmBMgr8g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 47rJbj6wBqz6tm6; Sun, 5 Jan 2020 13:58:25 +0100 (CET) In-Reply-To: <20200105123329.5019662bdf1895a4164faf62@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.65 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:15991 Archived-At: Thank you for the detailed explanation! By "process" I meant only "sequence of steps performed", the main thunk in run-fibers, separate from the steps that are run in the spawned fiber, not really OS process or thread. I will take a look again at the parallel forms and think about whether I want to use them or fibers. Originally I had my algorithm in Racket and could not get it to work in parallel, unless I explore places and serializable lambdas more. I think fibers are more flexible than the parallel forms though, as one could also build a pipeline using fibers or any kind of network of connected computation tasks, while the parallel forms split a task immediately and then join again. Not sure any of the additional flexibility of fibers helps me. Perhaps I can use both and abstract from it with an additional abstraction layer. Then my code could also be used more easily in other Schemes. This is my project: https://notabug.org/ZelphirKaltstahl/guile-ml/src/wip-port-to-guile I still am not sure though, if I can simply use any lambda I want and send that to a fiber, or I need to look out for things like "What is in the environment of the lambda?". It would be good to know that. I guess it depends on how data sent on channels is handled in the fibers library. Regards, Zelphir On 1/5/20 1:33 PM, Chris Vine wrote: > On Sun, 5 Jan 2020 02:30:06 +0100 > Zelphir Kaltstahl wrote: > [snip] >> This way of communication between the fiber and the main process seems >> in the style of Racket's places. Except that I can send normal >> procedures / lambdas to the fiber, which is great on a single machine, >> while I need to send serializable lambdas to Racket places (and I have >> not gotten to do that yet). >> >> Is there a restriction on the kind of lambdas I can send on a channel as >> I did in the example above? > I may well be missing your point, mainly because I don't know what you > mean by "the main process" - all the fibers are part of the same > process, and can be run in the same native thread if you want. > > run-fibers runs what amounts to a scheduler and does not return until > the thunk passed to it returns. So if by "the main proccess" you mean > the thunk which is running on a fiber scheduler, then you know it has > finished when run-fibers returns, after which you can execute what > other non-fiber code you want to execute. run-fibers will return the > value (if any) returned by the thunk which it runs. > > Within the thunk run by run-fibers, you normally synchronize using > channels. At it's absolute simplest it can be this: > > (display (run-fibers > (lambda () > (let ((channel (make-channel))) > (spawn-fiber > (lambda () > (sleep 1) ;; do some work > (put-message channel "hello world"))) > (simple-format #t "~a~%" (get-message channel)) > "finished\n")))) > > Here the "main" thunk (the one passed to run-fibers which returns > "finished\n") will not finish until the fiber thunk has finished, > because of the wait on the channel. If you spawn multiple fibers and > the "main" thunk does not wait for the fibers like this, and you > therefore need to ensure additionally that run-fibers does not return > until all the fiber thunks have finished, you can set the drain > argument of run-fibers to #t. Probably in that case your "main" thunk > will not return a meaningful value. > > You say you want "to parallelize some algorithm". If that is your main > aim, consider guile's parallel forms of parallel, let-par and friends. > > Chris >