This needs delimited continuations to prevent space leaks, doesn't it?

Unfortunately, these are not yet standardized.


Am Do., 6. Mai 2021 um 17:32 Uhr schrieb Alexey Abramov - levenson at mmer.org (via srfi-discuss list) <xxxxxx@srfi.schemers.org>:
Hi,

I am new here, but i think https://github.com/wingo/fibers
can be helpful.

--
Alexey

May 6, 2021 16:50:15 Amirouche <xxxxxx@hyper.dev>:

> Thanks for ending this monolog. And thanks for SRFI-18,
> it is very helpful, and I will use it to implement coop
> pre-SRFI.
>
> ref: https://srfi.schemers.org/srfi-18/srfi-18.html
>
> On 2021-05-06 16:26, Marc Feeley - feeley at iro.umontreal.ca wrote:
>> I’m not sure what your goal is with this SRFI.  Could you clarify?
>> SRFI-18 (Multithreading support) is supported by many Scheme
>> implementations and is the best thread API if you are interested in
>> portability accross Scheme implementations.  It seems some of the
>> things you are proposing have a direct link with SRFI-18 features, so
>> I don’t understand why a new SRFI is needed.
>
> So far, if we disregard PRIORITY, coop is only an alternative to
> SRFI-18.
>
> When priority is +inf.0 it should have exclusive access to a CPU.
> Otherwise it is a hint to implement fairness.
>
> Coop API surface is much smaller.
>
> If we disregard "existing mainstream knowledge" as is the case of a
> programmer without prior experience programming concurrent system:
> it is simpler.
>
> What I am exploring with that pre-SRFI is whether coop provides less
> guns to shoot myself in the foot compared to mutex and conditions.
>
> So far, the only problem with coop is producer or consumer starvation.