On Thursday, 8 August 2013 at 21:11:06 UTC, Ali Çehreli wrote:
An immutable on the receiving side is a request to the caller
that the data must be immutable. If you are casting data with
mutable indirection to immutable, anything can happen.
immutable data is by nature not synchronized because it is
read-only. (Of course you can synchronize if you know that it
is casted data to begin with.)
Have you considered the 'shared' attribute? You are still
responsible for dealing with race conditions.
Do you mean declaring the struct instance itself as shared and
then passing its pointer? If so, I could not get receive() to
catch it as anything other than a Variant, no matter how I tried.
shared IrcEvent evt = p.parse(raw);
tid.send(&evt);
/* ... elsewhere ... */
receive(
(shared IrcEvent* evt) {
writefln("%s: %s", typeof(evt).stringof, evt);
},
(Variant v) {
writefln("Variant: %s", v); // <-- this is where it
goes, as a shared(IrcEvent)*
}
);
Sending it by (shared) value hits the same assertion in
variant.d; target must be non-null. And if I still have to deal
with the race if I go with a shared pointer, as you say, then it
may be semantically more correct but my code will still be as
broken. :>
I understand that the pointer goes invalid when the scope ends --
I just... don't know what other approach to take if I can't pass
it by value.
I'm using gdc 4.8.1 (which is based on 2.062) and I would upgrade
in a heartbeat, but this is the latest version available in
Canonical's saucy repositories. It's not impossible to compile
and package it myself, and if that's the only solution available
then that's what I'll have to do. Iain Bucklaw seems to have a
personal repository[1] but its packages are from 2010, so it
seems I cannot ride on the success of others'. ;3
[1]: https://launchpad.net/~ibuclaw/+archive/ppa
