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
