To my understand, the current activity is to full fill the worker queue
first, then execute them one by one.
However, if the worker count is zero, the fulfillment will always return an
empty queue, so that the existing futures can't be executed.
I think the issue of the current implementation is to mix the two different
situations, thread-unsupported and single-CPU. The simplest fix is to make
sure there is always a worker count.
I will patch the document later.
Best regards.
On Tue, Aug 19, 2025, 06:21 Maxime Devos <maximede...@telenet.be> wrote:
> Right, the (max 1 ...) was the important part, the other thing was my
> mistake
>
> Looking at it again, your patch (both v1 and v2) is inconsistent with
> the documentation ("By default, the pool contains one thread per
> available CPU core, minus one, to account for the main thread"). You
> would need to adjust the documentation as well, to indicate it is has at
> least one thread.
>
> Also, %worker-count can still be 0 now, in case no thread support is
> available. So, when no thread support is available, the same would
> presumably happen. So if it is a bug in (ice-9 futures), it is not clear
> that it is actually fixed.
>
> Did you actually 'touch' to future to wait for their completion? Going
> by the code, it appears that if the future is neither started nor
> completed, then it will start processing futures (in the same thread,
> not another) (and after each processed future it checks again whether
> it's completed).
>
> So, in theory, futures should work even when %worker-count is zero.
>
> Note that the documentation says that things _may_ occur in parallel,
> not that they will be. It's presented as a way to utilise the
> 'multi-core' part of multi-core machines, so from that perspective,
> there is not much of a point to having worker threads (*) when there is
> only a single 'core'.
>
> (*) still some, in case of blocking I/O (but futures are explicitly not
> intended for that)
>
> If you intend to change the semantics to guarantee that futures will be
> processed even if they are never touched(**), that's really something
> that needs to be in the documentation.
>
> (**) under the assumption that the other futures eventually finish, as
> there is no automated preemption system.
>
> Best regards,
> Maxime Devos
>
>
