Possible to pass a member function to spawn?
Jacob Carlborg
doob at me.com
Wed Feb 8 05:11:56 PST 2012
On 2012-02-08 12:33, Manu wrote:
> On 8 February 2012 01:53, Timon Gehr <timon.gehr at gmx.ch
> <mailto:timon.gehr at gmx.ch>> wrote:
>
> On 02/08/2012 12:09 AM, Manu wrote:
>
> On 8 February 2012 00:33, Sean Kelly <sean at invisibleduck.org
> <mailto:sean at invisibleduck.org>
> <mailto:sean at invisibleduck.org
> <mailto:sean at 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
More information about the Digitalmars-d
mailing list