Possible to pass a member function to spawn?

[Jacob Carlborg]

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