On Sun, 17 Jul 2016 23:20:09 GMT, Øivind Loe wrote:

This came up recently and I couldn't remember why I chose runTask, but
I think that runWorkerTask would be the right choice. That would not
be a real thread per spawn, but tasks would be mapped to a thread pool
where the number of threads equals the number of total hardware threads
by default.

Another possibility would be to make this configurable and to provide
the choices runTask, runWorkerTask and new Thread.

The problem here is that unit-threaded should not be dependent on vibe.d.. With this new definition of spawn(..), unit-threaded suddenly has to become aware of vibe.d in order to work, and have a special case if vibe.d is present.

I looked at using 'new Task', but my impression is that then the 'Tid' struct would not be generated, and the newly created struct would not be able to receive messages using std.concurrency.

Preferably, vibe.d should not change the function of std.concurrency (improving on it is ok).

Do you have any ideas on how I can address this?

As a hack, I am now using runWorkerTask_unsafe(..) in spawn, as the safe version would not take the delegate. I also had to change this function to public in order to get access to it.

Can you please sort this out for the next vibe.d version?