std.concurrency and efficient returns

[Robert Jacques]

On Sun, 01 Aug 2010 19:22:10 -0400, Jonathan M Davis  
<jmdavisprog at gmail.com> wrote:

> On Sunday 01 August 2010 08:55:54 Robert Jacques wrote:
>> Hi Jonathan,
>> It sounds like what you really want is a task-based parallel programming
>> library, as opposed to concurrent thread. I'd recommend Dave Simcha's
>> parallelFuture library if you want to play around with this in D
>> (http://www.dsource.org/projects/scrapple/browser/trunk/parallelFuture/para
>> llelFuture.d). However, parallelFuture is currently unsafe - you need to
>> make sure that logically speaking that data the task is being passed is
>> immutable. Shared/const/immutable delegates have been brought up before  
>> as
>> a way to formalize the implicit assumptions of libraries like
>> parallelFuture, but nothing has come of it yet.
>> As for std.concurrency, immutability is definitely the correct way to  
>> go,
>> even if it means extra copying: for most jobs the processing should
>> greatly out way the cost of copying and thread initialization (though
>> under the hood thread pools should help with the latter). A large amount
>> of experience dictates that shared mutable data, let alone unprotected
>> mutable data, is a bug waiting to happen.
>> On a more practical note, if you relaxing either 1) or 2) can cause  
>> major
>> problems with certain modern GCs, so at a minimum casts should be  
>> involved.
>
> I totally agree that for the most part, the message passing as-is is a  
> very good
> idea. It's just that there are cases where it would be desirable to  
> actually
> hand over data, so that the thread receiving the data owns it, and it  
> doesn't
> exist anymore in the sending thread. I'm not sure that that's possible  
> in the
> general case as nice as it would be.

Oh, sorry I missed that point. That has been seriously discussed before  
under the moniker of a 'unique'/'mobile' type. You might want to look up  
the dmd-concurrency mailing list or Bartoz's old blogs  
bartoszmilewski.wordpress.com. If I recall correctly, there was some plans  
to support the library unique struct in std.concurrency. However, Walter  
found that trying to fit it into the type system as a whole was too  
complex, so the concept is being left to the simpler library solution.