From: Andy Wingo <wingo@pobox.com>
To: Amirouche Boubekki <amirouche@hypermove.net>
Cc: Kristofer Buffington <kristoferbuffington@gmail.com>,
guile-user@gnu.org, help-guix@gnu.org,
Help-Guix <help-guix-bounces+amirouche=hypermove.net@gnu.org>
Subject: Re: Introducing GNUPaste (and guile-wiredtiger future)
Date: Mon, 18 Dec 2017 10:06:25 +0100 [thread overview]
Message-ID: <876094s8vi.fsf@igalia.com> (raw)
In-Reply-To: <11c569c155672a6da5fce60c67b358f4@hypermove.net> (Amirouche Boubekki's message of "Sun, 17 Dec 2017 15:39:52 +0100")
On Sun 17 Dec 2017 15:39, Amirouche Boubekki <amirouche@hypermove.net> writes:
> Basically, guile-wiredtiger is not compatible yet with fiber
> in the general case, because fiber will spawn several threads
> and several fibers in each thread (and I think that fibers
> can be stolen by other threads but I am not sure).
Note that it's possible to run fibers with only one kernel thread. See
the docs. Also note that in fibers (and indeed in Guile threads), a
newly spawned fiber (or thread) inherits the fluid values that were
current when the thread was spawned. Fluid values in other fibers or
threads are unaffected.
Anyway I reply to offer some more general notes :) If what you need is
sequential access to a database, you can arrange to access the database
from a single fiber. That fiber can communicate with others via
channels (for example). If the fiber migrates to another threads, that
usually doesn't matter -- it's as if a kernel thread migrated to a
different CPU. The memory model of Guile and fibers ensures that there
will be no problems. You do end up having to route database requests to
that fiber, usually via messages over channels, but that can be OK --
see
https://blog.acolyer.org/2017/12/04/ffwd-delegation-is-much-faster-than-you-think/.
Sometimes though you need real thread affinity between some external
resource and a fiber. In that case the usual solution is to spawn a
thread instead of a fiber, and access the resource only in that thread.
You can still use channels to communicate between that thread and other
fibers running on your system, if that's what you want.
Cheers,
Andy
prev parent reply other threads:[~2017-12-18 9:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-17 14:39 Introducing GNUPaste (and guile-wiredtiger future) Amirouche Boubekki
2017-12-17 17:35 ` Kristofer Buffington
2017-12-18 19:38 ` Amirouche
2017-12-18 9:06 ` Andy Wingo [this message]
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=876094s8vi.fsf@igalia.com \
--to=wingo@pobox.com \
--cc=amirouche@hypermove.net \
--cc=guile-user@gnu.org \
--cc=help-guix-bounces+amirouche=hypermove.net@gnu.org \
--cc=help-guix@gnu.org \
--cc=kristoferbuffington@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).