Re: guile fibers - looking for adivce

[Chris Vine]

On Mon, 7 Sep 2020 17:25:38 -0700
Aleix Conchillo Flaqué <aconchillo@gmail.com> wrote:
[snip]
> To be honest, I've never used GOOPS so things might be a bit more
> complicated there, I don't know. But it sounds like you have two options:
> 
> - Create a fiber with the object and pass data from the object using
> channels to other fibers. Then return data to the main fiber (or the fiber
> that has the object) through a channel and update your object.
> - Make the object global and have fibers that update the object. In this
> case you would need to use mutexes.
> 
> Or maybe you find another way?

The OP should use channels.  It is a bad idea to mix mutexes (which are
a construct for native OS threads) with fibers, because fibers run as
delimited continuations, a group of which may be running on a
particular thread.  To synchronize fibers, you use channels.

Guile's atomic variables (boxes) are available and can be used with
fibers because they do not block, but to use them you really need to
know what you are doing, just as you do if you are using them in C.
Atomic variables do synchronize memory, but they do not provide mutual
exclusion (they don't block) and so require expert skills: don't use
them if you don't know how to use atomic compare-and-swap correctly.

This is what the guile fibers manual has to say:

"Guile’s mutexes are an even worse solution with a Fibers system. It is
a bad idea for a fiber to grab a Guile mutex, because if the mutex is
not available, Guile will suspend not just the fiber that is running
but the entire kernel thread.  If the mutex is available, the fiber
obtains it, cool; but if it the fiber suspends while holding a mutex,
that’s bad news.  Any fiber trying to acquire a mutex while a suspended
fiber from the same thread already has the mutex will result in an
error: as Guile thinks that the mutex has already been acquired by the
current thread, it detects recursion and bails out.

...

"The root of this problem is that Guile associates mutexes with kernel
threads, not fibers. It would be possible however to make a
Fibers-appropriate implementation of mutexes, but we suggest that users
try atomic boxes or channels instead. If you do use mutexes, make sure
you disable preemption (possibly by a local call to
call-with-blocked-asyncs), and take care to never suspend a fiber while
it owns any mutex."