Am 04.02.2013 10:07, schrieb Nathan M. Swan:

Here's the architecture I'm thinking of; might conflicts with std.concurrency and vibe.d arise?

At launch, a simulator thread (Tid) is spawned and saved as a global variable. It doesn't call any
vibe functions, just sends and receives Start/Stop/StatusUpdate/etc messages from vibe.d HTTP
response fibers.


Should be fine. The HTTP thread just shouldn't wait/block (too long) for messages or Tids.

Full multi-threading support is still on my TODO list and in a first version I wanted to include an
API compatible module akin to std.concurrency but with full Fiber/AIO support - in the hope that
std.concurrency can be extended later to support it directly (by using different synchronization
primitives). It's already started, but I'm not sure if time permits to finish it this month or next.