On Mon, 27 Jan 2014 14:21:13 GMT, Sönke Ludwig wrote:

Maybe it was just a suboptimal example, but since I/O should usually use async I/O, simply using runTask instead of runWorkerTask should suffice here, so no Isolated or shared would be necessary.

But a very similar and slightly more general concept are "promises" or "futures". Those in two flavors - one for normal tasks and one for worker tasks - would be a valuable addition for vibe.core.concurrency for sure. I didn't use them much in practice personally, but they are also a very nice way to add concurrency to an existing code base.

Yes it was a bad example, I like to think it would be effective to run long computations as well without thinking too much about it.

I know futures very well from the C++11 specs and Qt, while I may not be the best working with them I get very passionate very easily when they're involved

http://en.cppreference.com/w/cpp/thread/future
https://qt-project.org/doc/qt-5/qtconcurrent-index.html

I prefer Qt's implementation, where you can poll for progress, pause, cancel, synchronize them, etc.

In vibe.d, I think all futures would have to be spawned by a dedicated task that communicates back and forth through a task message queue. Using some CTFE, the main task could synchronize them together, and assuming they mutate shared data, that part could be optimized at compile-time automatically, with atomicity in ways that are causing heavy headaches to a lot of people right now. There's a lot of features from D that could open the door to some very complex atomic operations. It could become one of the most significant strengths imo.