Am 10.11.2013 22:17, schrieb Shammah Chancellor:
On 2013-11-10 08:21:09 +0000, Sönke Ludwig said:
On Sat, 9 Nov 2013 14:45:30 -0500, Shammah Chancellor wrote:
Sönke,
Alright. I've tried using shared classes, Isolated classes, and
immutable classes. None of them work for a variety of reasons:shared classes <-- Don't work because of external dependencies.
Making every member variable shared, breaks too much stuff.Isolated classes <-- I need to be able to send the same reference to
multiple threads, so .move() is out of the question.Immutable classes <-- Can't even get them to instantiate since the
constructors have to be strongly pure. Also, I can't deserialize into
an immutable class!How am I supposed to send complex class messages?
R/
Shammah
You should try the
lock()function invibe.core.concurrency! It
uses a scheme if shared usage that Walter Bright once proposed in a
discussion and it makes shared with classes actually bearable.Basically you just define a normal class without any shared
annotations, but create the instance usingauto c = cast(shared)new<br>C. You will then not be able to use any methods of that class, but
callingc.lock()will give you back scoped access while the
instance's monitor is locked. Beware though that only access topure
methods is allowed to guarantee safety (no unshared references must
escape), but this is currently not enforced due to compiler issues I
had some time ago (not sure how DMD 2.064 behaves now).Ahh.. Handy. There is so much good stuff hiding out in vibe-d. Is
there any consideration for trying to get this sort of stuff commited
back phobos?R/
Shammah
Yes, a lot of stuff (e.g. everything in vibe.util and
vibe.core.concurrency) would be great to have in Phobos. However,
actually getting code in Phobos is a very involved process and I don't
have the time to do so. But many things are also good prototypes against
which actual new Phobos features can be measured (e.g. the new
std.allocator framework) and which will then be replaced by the Phobos
versions eventually.