RejectedSoftware Forums

Sign up

Why does vibe.d has its own concurrency system

I am curious why vibe.d uses its own concurrency system instead of just using std.parallelism.TaskPool/Task for example?

What I would want is a system that maps N tasks onto M threads. Each task represents a unit of work and each task can also spawn tasks and wait on its result. But if one task has to wait on another task it should be rescheduled and should not block a thread.

It seems that std.parallelism does all that just fine. Is there anything inherently bad with std.parallelism?

Re: Why does vibe.d has its own concurrency system

Am 19.04.2016 um 14:25 schrieb Maik Klein:

I am curious why vibe.d uses its own concurrency system instead of just using std.parallelism.TaskPool/Task for example?

What I would want is a system that maps N tasks onto M threads. Each task represents a unit of work and each task can also spawn tasks and wait on its result. But if one task has to wait on another task it should be rescheduled and should not block a thread.

For vibe.d that N-M mapping would be runWorkerTask(). The wait part
should word as expected.

It seems that std.parallelism does all that just fine. Is there anything inherently bad with std.parallelism?

Nothing bad about std.parallelism. vibe.d just uses a more fine-grained
approach where a task is based on a fiber, whereas std.parallelism has
monolithic tasks that block a thread as long as they run. But hopefully
it will be possible to integrate the two one day, as it has already
partially happened with std.concurrency.

Re: Why does vibe.d has its own concurrency system

On Tue, 19 Apr 2016 23:43:30 +0200, Sönke Ludwig wrote:

Am 19.04.2016 um 14:25 schrieb Maik Klein:

I am curious why vibe.d uses its own concurrency system instead of just using std.parallelism.TaskPool/Task for example?

What I would want is a system that maps N tasks onto M threads. Each task represents a unit of work and each task can also spawn tasks and wait on its result. But if one task has to wait on another task it should be rescheduled and should not block a thread.

For vibe.d that N-M mapping would be runWorkerTask(). The wait part
should word as expected.

It seems that std.parallelism does all that just fine. Is there anything inherently bad with std.parallelism?

Nothing bad about std.parallelism. vibe.d just uses a more fine-grained
approach where a task is based on a fiber, whereas std.parallelism has
monolithic tasks that block a thread as long as they run. But hopefully
it will be possible to integrate the two one day, as it has already
partially happened with std.concurrency.

Re: Why does vibe.d has its own concurrency system

Sorry copy and paste failed

Nothing bad about std.parallelism. vibe.d just uses a more fine-grained
approach where a task is based on a fiber, whereas std.parallelism has
monolithic tasks that block a thread as long as they run. But hopefully

Could you explain this a bit more? When would you need to interrupt a task?

I have done a few experiments myself with std.parallelism and it seems that when a task has to wait for another task to finish, it will reschedule that task instead of blocking that thread.

The only thing that seems to be missing is some sort of priority system.