In section 4.3, it would seem more natural to say "low" and "high" rather than "low" and "up".

Kevin

On Mon, Jan 11, 2010 at 5:26 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> I remembered there are issues with attachments, so I made draft 3 available from:
>
> http://erdani.com/d/fragment.preview.pdf
>
>
> Thanks,
>
> Andrei
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100112/49fdd880/attachment.htm>

Andrei Alexandrescu wrote:
>
> You're right, sorry. We've been back and forth on this a couple of times. The knee-jerk reaction is that shared is strictly more restrictive than non-shared, so it's fine to convert from non-shared to shared. But in reality shared and non-shared are in no subtyping relationship; a lot of parallels could be drawn with immutable: immutable is like shared, const would be like mayormaynotbeshared.
>

Yes, it's an easy trap to fall into, and I fell into it several times. Thread local cannot be implicitly converted to shared.

Done, thanks.

Andrei

Kevin Bealer wrote:
> In section 4.3, it would seem more natural to say "low" and "high" rather than "low" and "up".
> 
> Kevin
> 
> On Mon, Jan 11, 2010 at 5:26 AM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
> 
>     I remembered there are issues with attachments, so I made draft 3
>     available from:
> 
>     http://erdani.com/d/fragment.preview.pdf
> 
> 
>     Thanks,
> 
>     Andrei
> 
>     _______________________________________________
>     dmd-concurrency mailing list
>     dmd-concurrency at puremagic.com <mailto:dmd-concurrency at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

Le 2010-01-11 ? 17:22, Andrei Alexandrescu a ?crit :

> You're dead on.
> 
> I'm thinking of solving that problem through two mechanisms:
> 
> a) A deepCopy protocol. deepCopy(value) will create a copy of value that shares absolutely nothing with the original value. The type system won't be able to always ensure that, so we'll need to rely on the user to implement it properly. With deepCopy in place, UniqueArray works great - all you have to do is return a deepCopy() of the requested element. That way the addresses of the elements or their fields etc. never escape.

At this point, we have uniqueCopy and deepCopy. Couldn't we get rid of .dup/.idup for consistency, using the "copy" instead of "dup", for consistency?


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

As of draft 5, Benjamin's point below still has not been addressed.  I realized it again when I started perusing it.  I think it is a very valid point -- asyncSort, yeah it sorts data and throws it away.  Not a very compelling example.  It might segue well into the message passing section -- continue with the same example.

-Steve



----- Original Message ----
> From: Benjamin Shropshire <benjamin at precisionsoftware.us>
> 
> I'm not sure where your going with the asyncSort example. It's a good illustration for what it's showing, but what will the function /do/ withe the sorted data? Unless you can come up with a nice clean and elegant way to get it back to the main thread, I'd chose a different task (find-and-print for example) that the reader won't expect to return something. OTOH if you do have a nice clean and elegant conclusion, rock on!

I agree, will look into it.

Andrei

Steve Schveighoffer wrote:
> As of draft 5, Benjamin's point below still has not been addressed.  I realized it again when I started perusing it.  I think it is a very valid point -- asyncSort, yeah it sorts data and throws it away.  Not a very compelling example.  It might segue well into the message passing section -- continue with the same example.
> 
> -Steve
> 
> 
> 
> ----- Original Message ----
>> From: Benjamin Shropshire <benjamin at precisionsoftware.us>
>>
>> I'm not sure where your going with the asyncSort example. It's a good illustration for what it's showing, but what will the function /do/ withe the sorted data? Unless you can come up with a nice clean and elegant way to get it back to the main thread, I'd chose a different task (find-and-print for example) that the reader won't expect to return something. OTOH if you do have a nice clean and elegant conclusion, rock on!
> 
> 
> 
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

Benjamin Shropshire wrote:
> Someone should look at ways to make implement deepCopy and serialize/deserialize via a single source. Both amount to "Walk this tree and render it as something" (or in the deserialize case render it from something) where deepCopy is rendering to another tree and serialize/deserialize is rendering to/from a bit stream. Not joining these seems wastefull. I've got a lib that has the "easy 80%" of the serialize/deserialize done that I'd donate if anyone cares.

That would be great! Sorry I forgot about this message when jokingly tasking Michel with implementing serialization.

If you could share your design, please do, that would be great. With luck, you have some overview documentation.


Andrei