[stdlib-sig] futures - a new package for asynchronous execution

Brian Quinlan brian at sweetapp.com
Sun Feb 21 11:49:05 CET 2010

A few extra points.

On 21 Feb 2010, at 14:41, Jeffrey Yasskin wrote:
> * I'd like users to be able to write Executors besides the simple
> ThreadPoolExecutor and ProcessPoolExecutor you already have. To enable
> that, could you document what the subclassing interface for Executor
> looks like? that is, what code do user-written Executors need to
> include? I don't think it should include direct access to
> future._state like ThreadPoolExecutor uses, if at all possible.

One of the difficulties here is:
1. i don't want to commit to the internal implementation of Futures
2. it might be hard to make it clear which methods are public to users  
and which methods are public to executor implementors

> * Could you specify in what circumstances a pure computational
> Future-based program may deadlock? (Ideally, that would be "never".)
> Your current implementation includes two such deadlocks, for which
> I've attached a test.

Thanks for the tests but I wasn't planning on changing this behavior.  
I don't really like the idea of using the calling thread to perform  
the wait because:
1. not all executors will be able to implement that behavior
2. it can only be made to work if no wait time is specified


More information about the stdlib-sig mailing list