On 2012-02-08 12:33, Manu wrote:
On 8 February 2012 01:53, Timon Gehr <timon.g...@gmx.ch
<mailto:timon.g...@gmx.ch>> wrote:
On 02/08/2012 12:09 AM, Manu wrote:
On 8 February 2012 00:33, Sean Kelly <s...@invisibleduck.org
<mailto:s...@invisibleduck.org>
<mailto:s...@invisibleduck.org
<mailto:s...@invisibleduck.org>__>> wrote:
On Feb 6, 2012, at 1:38 PM, Oliver Puerto wrote:
> Hello,
>
> I'm very new to D. Just started reading "The D programming
language". I should read it from beginning to end before posting
questions here. I know ... But I'm just too impatient. The issue
seems not to be that simple, nevertheless. The code below
compiles
with Visual Studio.
>
> I want to have something like my actor class that I can start
running in it's own thread like in Scala or other languages that
support actors. So at best, I would like to do something
like this:
>
> MyActor myActor = new MyActor();
> auto tid = spawn(&start, &myActor.run());
This should work:
void runActor(shared MyActor a) { (cast(MyActor)a)).run(); }
MyActor myActor = new MyActor();
auto tid = spawn(cast(shared MyActor) myActor, &runActor);
See, my conclusion is, whenever using this API, you inevitably
have dog
ugly code.
If it is combined with OO.
The OO changes nothing, the casting is what I'm getting at.
That code is barely readable through the casts... I can only
draw this up to faulty API design.
I understand the premise of 'shared'-ness that the API is trying to
assert/guarantee, but the concept is basically broken in the
language.
The concept is not broken at all. There are just too few type system
features to conveniently support the concept.
... I think you contradicted yourself one sentence after the other :)
You can't use this API at all with out these blind casts, which is,
basically, a hack, and I am yet to see an example of using this API
'properly'.
Passing value type and/or immutable messages works well.
I guess so, but I think this would be relatively rare. Many immutable
things may just be addressed directly/globally.
Maybe it's just my experience of threading, but I basically never spawn
a thread where I don't intend to pass some sort of 'workload' to it... I
shouldn't have to jump through hoops to achieve that basic task.
The casts are totally self defeating.
They indicate a potentially unsafe operation.
Sure, but what's the point of 'indicating' such a thing, when the ONLY
way to deal with it, is to add ugly blind casts? You are forced to
ignore the warning and just cast the 'problem' away.
std.concurrency really should allow unique references to a
non-shared type to be passed as well, using something similar to
assumeUnique.
Something like that should exist in the language (... or shared
should
just not be broken).
How would you improve usability of the shared qualifier without some
kind of ownership type system?
I've thought about that... but I've got nothing. The shared concept
seems basically broken to me. It's nothing more than a
self-documentation keyword, with the added bonus that it breaks your
code and forces casts everywhere you touch it.
It creates a boundary between 2 worlds of objects. Nothing shared can be
used in an un-shared environment (ie. all your code), and nothing
unshared can be passed to a shared environment... and there's no
implicit(/safe) transfer between the 2 worlds.
The ONLY way to interact is explicit cast, which doesn't guarantee any
safety, you just have to type it wherever the compile errors pop up. So
what's the point? Without a way for the language to assert what
transfers between worlds are safe or not, the whole premise is self
defeating.
Passing args by value seems to be the only solution, but that doesn't
work in an OO environment.
You would basically need to serialize an object or hierarchy of objects
to be able to pass it to another thread.
Do you have any ideas how to make it work?
I get the feeling, as I say, shared is a nice idea, but it's basically
broken, and the language doesn't have any mechanism to really support
it. As is, it's nothing more than an info-keyword that makes your code
ugly :/
Using a template like assumeUnique is no better
than the ugly cast. What does it offer over a cast?
Nothing. I prefer cast(immutable).
I'd prefer to not have shared at all in it's current state. It adds zero
value that I can see, and has clear negative side effects.
I agree with you in general.
--
/Jacob Carlborg
