On 2014-01-28 13:31, Etienne wrote:
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.
I was reading this
http://www.fieryrobot.com/blog/2010/06/27/a-simple-job-queue-with-grand-central-dispatch/
and had a few ideas that I wanted to keep written here as a kind of journal of crazy ideas on the subject. It's not a feature request, just some ideas.
The idea is to either create a specific task for each mutable variable which handles the operations and operate through task message queue, or an access queue for them in the central task and operate with it through task message queue. I think it mostly depends on the cost of context switching. Tasks would have priority levels, the central task (dispatcher) having a 100 priority level means it's called every time another task in its thread yields.
Worker tasks communicate their atomic operations to the central task through the task message queue, this operation is adjusted to a predicted order of operation.
The goal would be to have an algorithm that automatically optimizes algorithms for concurrency, e.g. give it the fibonacci sequence algorithm and have it saturate the cpus with worker tasks.