Possible to pass a member function to spawn?

[Manu]

On 8 February 2012 01:53, Timon Gehr <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**>> 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120208/8c2180f2/attachment-0001.html>