unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Chris Vine <vine35792468@gmail.com>
To: guile-user@gnu.org
Subject: Re: Guile fibers return values
Date: Sun, 5 Jan 2020 14:28:49 +0000	[thread overview]
Message-ID: <20200105142849.25b963215b4b7ccd2115d22a@gmail.com> (raw)
In-Reply-To: <f28124ab-e09a-76d0-8d31-c52caffcb50e@posteo.de>

On Sun, 5 Jan 2020 13:58:24 +0100
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
> 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.

Fibers are more flexible than guile's parallel forms as you say (of
course, if you have your own thread pool available that can also be
more flexible than the parallel forms), but fibers' main other feature
is that they will multi-plex i/o operations on the same native thread
using guile's suspendable ports and coroutines.  Any one native OS
thread run by the fibers' scheduler may therefore have more than one
coroutine running on it.  So, beware having blocking operations when
using fibers, because between fibers running on the same native OS
thread, concurrency is co-operative - coroutine task switching occurs on
a port suspending or the fiber yielding, although there is some work
stealing implemented between OS threads which will help you out.  (From
the blocking point of view, do not use the simple-format procedure as in
my toy example because it is not suspendable-port-safe.)

If your work is i/o-bound rather than cpu-bound, fibers are likely to be
especially useful.

> 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.

The lambda closures passed to run-fibers and spawn-fiber are like any
other lambda closure.  In particular, beware of closures with shared
mutable state.  Apart from that you should be fine as regards closures
but I am not convinced that I sufficiently understand your use case to
comment further.  On data sent through channels, I haven't looked at it
but I have always assumed that objects such as lists, vectors, records
and so forth which are passed through channels are passed by reference
in the ordinary way, so don't mutate them after putting them in a
channel if more than one fiber may subsequently have them in use
concurrently.  The purpose of channels is to provide safe
synchronization.

Chris



  reply	other threads:[~2020-01-05 14:28 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
2020-01-05 14:28     ` Chris Vine [this message]
     [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=20200105142849.25b963215b4b7ccd2115d22a@gmail.com \
    --to=vine35792468@gmail.com \
    --cc=guile-user@gnu.org \
    /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).