From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Chris Vine <vine35792468@gmail.com>
Cc: guile-user@gnu.org
Subject: Re: Guile fibers return values
Date: Sun, 5 Jan 2020 13:58:24 +0100 [thread overview]
Message-ID: <f28124ab-e09a-76d0-8d31-c52caffcb50e@posteo.de> (raw)
In-Reply-To: <20200105123329.5019662bdf1895a4164faf62@gmail.com>
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 <zelphirkaltstahl@posteo.de> 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
>
next prev parent reply other threads:[~2020-01-05 12:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-05 1:30 Guile fibers return values Zelphir Kaltstahl
2020-01-05 12:33 ` Chris Vine
2020-01-05 12:58 ` Zelphir Kaltstahl [this message]
2020-01-05 14:28 ` Chris Vine
[not found] ` <20200105142358.4ad96d15a23a0b947b2d55e3@gmail.com>
2020-01-05 18:22 ` Zelphir Kaltstahl
2020-01-05 21:45 ` Chris Vine
2020-01-06 19:42 ` Zelphir Kaltstahl
2020-01-06 21:14 ` Chris Vine
2020-01-06 21:47 ` John Cowan
2020-01-06 22:45 ` Zelphir Kaltstahl
2020-01-07 1:36 ` John Cowan
-- strict thread matches above, loose matches on Subject: below --
2020-01-04 22:49 Zelphir Kaltstahl
2020-01-05 2:42 ` John Cowan
2020-01-05 12:46 ` Zelphir Kaltstahl
2020-01-14 10:59 ` Amirouche Boubekki
2020-01-15 0:04 ` Zelphir Kaltstahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f28124ab-e09a-76d0-8d31-c52caffcb50e@posteo.de \
--to=zelphirkaltstahl@posteo.de \
--cc=guile-user@gnu.org \
--cc=vine35792468@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).