Am 16.07.2016 um 16:24 schrieb Øivind Loe:
I am trying to get the "unit-threaded" unittesting library to work in an application that uses vibe.d, but am running into some issues.
It seems like unit-threaded is relying on std.concurrency.spawn to create new logical threads for the tests it is going to run, but it seems like vibed is redirecting this to runTask, and runTask seems like it is creating a fiber.
How is this supposed to work? What function in std.concurrency can unit-threaded use and reliably get a thread (where I can later use vibed functionality as a part of my tests)?
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.