> This is fantastic! We really need something like this in a Facebook
> project.
That's pleasing to hear, although I'm pretty sure Facebook is far from
being the only organization who will benefit from this ;)
> Would be appropriate for you to consider making a bid for adding it
to Phobos?
Thanks for the invitation, I'll start working on a phobos fork with this
added into std.async and re-licensed to Boost. Would that be an
appropriate namespace?
> In that case one issue to address is integrating std.concurrency
> with the event loop, i.e. registering an event handler should be
> possible for a thread message as well.
Of course, the libasync.threads module already has a good foothold on
the strategy, so a newer/better std.concurrency could deprecate parts of
this module by offering an adapted message queue that allows threads
with an event loop to communicate with threads that have one or not, in
both directions.
> Do I understand correctly that it is similar library to boost.asio
(EventLoop being equivalent of asio::io_service)?
That's right, but instead of io_service::run() you call
eventloop.loop(). In both cases, it's a wrapper around epoll_wait
(linux), kqueue (osx/bsd) or MsgWaitForMultipleObjects (windows) with a
timeout parameter. It waits for the objects supplied by the library. The
"strands" feature is pretty much covered by the vibe.d tasks if you're
using the driver I wrote for it.
