On Tue, 12 Mar 2013 10:15:22 GMT, Martin Drasar wrote:
On Wed, 28 Nov 2012 10:40:11 +0100, Sönke Ludwig wrote:
Just for the record, I would also like to have something like std.concurrency available in vibe.d
and probably will do an implementation with a compatible API at some point. The arguably better
alternative would be to extend std.concurrency so that it is able to use fibers and custom
synchronization primitives. But since that will probably not happen anytime soon (or at all), my
plan is to go with the former solution, although it kind of hurts to duplicate Phobos functionality.Hi, I was out of D development for some time, but I am now back and I would like to do something about the concurrency issues.
Could you please take a look at 'std.asio' thread in the D newsgroup (http://forum.dlang.org/thread/513E0110.7090703@ics.muni.cz) and tell how is the situation?Also - is there e.g. some isolated problem with the concurrency that I can help you with?
Cheers,
Martin
The current state is that I added a basic implementation of a vibe.d compatible std.concurrency clone (vibe.core.concurrency - can be swapped for std.concurrency in most cases without changes). It's not really tested well but basically seems to work.
The major missing thing though is the Isolated!T system. It is actually there, but I need to make some alternative implementations for some std.traits templates, because they are broken in 2.062. Once this is done, the most important part will be to carefully go through the whole vibe.d API to make everything statically thread-safe (type checked) as far as possible. The resulting API should then more or less be the final one that should only receive backwards compatible changes for the upcoming 0.8.x stable branch.
Mid-term I would then like to get some changes in std.concurrency that would make it compatible with the fiber-based locking in vibe.d (basically all that is needed is a way to make std.concurrency use vibe.core.sync.TaskMutex instead of core.sync.mutex.Mutex).
The thing with a possible std.asio is (I have recently also had a short talk about this with Vladimir Panteleev, who has done a lot with AIO in the past) that I can guarantee that I won't have time to do something for in in at least roughly the next 6 months. But once I have the time, I would gladly help to get such an abstraction in place and base the fiber system on top of that instead of the current driver implementations.