Re: [PATCH] Fix futures, %worker-count shouldn't be zero to prevent halting

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