Philip McGrath schreef op ma 28-03-2022 om 20:14 [-0400]: > Maybe it would be enough for this case for Fibers to provide variants of > `dynamic-wind` and/or `call-with-continuation-barrier` that cooperate > with the Fibers implementation. I don't know if that would be possible > of not—in addition to my limited familiarity with Fibers, I have not > read all of the related literature that Alexis, Matthew, and Matthias > Felleisen discuss in [5] and [6]—again, I am not an expert! Fibers' context switching is based on continuations. By definition, ‘call-with-continuation-barrier’ must create a continuation barrier (and as a consequence, interfere with Fibers' context switching). It can be important to let 'call-with-continuation-barrier' (*) actually create a continuation barrier, even when fibers is used, e.g. to not create deadlocks (or livelocks or whatever, I don't know the terminology) when POSIX mutexes are used. As such, as-is, I don't think so. Unless Guile could add some kind of '#:key "foobar"' argument to 'call- wih-continuation-barrier' and 'call-with-prompt/abort-to-prompt' -- the idea is that, by default, a continuation barrier cannot be passed, unless a matching key is supplied. So you could have a continuation barrier that allows context switching, but not continuing with raise- continuable or amb. The unwind-protect defined at looks interesting, although it needs to be generalised to remove the global variables (for multi-threading) and it needs to be verified whether it interacts well with exeption handling. Greetings, Maxime. (*) Actually, 'call-with-continuation-barrier' and 'dynamic-wind' are already a bit of a lie, since the kernel ignores them when context switching ... Maybe continuation barriers and {un,re}winding is a matter of perspective?