Re: Introducing GNUPaste (and guile-wiredtiger future)

[Andy Wingo <wingo@pobox.com>]

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