Are you referring to UniqueArray? It will only work with primitive types because it has no control over member functions of structs and classes that escape addresses. Maybe we could make it to work with Tuple too because Tuple is under the control of the stdlib.

Andrei

Michel Fortin wrote:
> Le 2010-01-11 ? 5:20, Andrei Alexandrescu a ?crit :
> 
>> I attach a fresh draft. This is qualitatively different from all others because it includes description of code that doesn't exist yet, so it's a great opportunity for those of you who'd want to help.
> 
> [...]
> 
>> Let me kindly ask you again to contribute by carefully looking over the material and ferreting out the inevitable mistakes, small and large. This is the perfect time to contribute by making sure D won't have some warts we need to put with from now on.
> 
> About unique... how far can it get without compiler support? It's pretty easy with primitive types, but when it comes to structs and classes, is there a way to enforce that they won't take take their own address (or the address of a member) and leak it elsewhere, in the constructor, in another member function, or even from an external function?
> 
> Or will unique work only with primitive types?
> 

Minor comment... druntime will need access to the atomics module too, so it either needs to live there or for a version to be in both places.  I guess importing std.concurrency could import core.atomic or whatever though, to make this invisible to the user.

Yah, let's focus on having std.concurrency the be-all end-all module for concurrency-related stuff.

Code starts looking real good doesn't it? Can't wait to get started on threads passing messages to each other.

Any implementation difficulties anyone is seeing so far?


Andrei

Sean Kelly wrote:
> Minor comment... druntime will need access to the atomics module too, so it either needs to live there or for a version to be in both places.  I guess importing std.concurrency could import core.atomic or whatever though, to make this invisible to the user.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

On Jan 11, 2010, at 12:30 PM, Andrei Alexandrescu wrote:
> 
> Any implementation difficulties anyone is seeing so far?

The trick will be safely passing structured types containing references.  Initially we could simply forbid this, but we'll have to deal with it for serialization eventually.  I haven't run into any problems spawning threads using the new approach, passing messages via copying, etc though.  I expect once I start adding "shared" to the implementation I'll find myself wishing for tail-shared (for performance reasons, in instances where I know the reference isn't shared), so perhaps I should try that soon.

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.

b) A serialization protocol. When doing IPC/IMC (M = machine) we'll need to serialize and deserialize objects into streams of bits. deepCopy can't help there.

We could solve both problems with (b) because deserializing a bitcopy will by necessity create a deep copy (you can't serialize a reference/pointer). But I'm still willing to define deepCopy because it seems silly to serialize/deserialize objects if all I want is to pass them to another thread.


Andrei

Sean Kelly wrote:
> On Jan 11, 2010, at 12:30 PM, Andrei Alexandrescu wrote:
>> Any implementation difficulties anyone is seeing so far?
> 
> The trick will be safely passing structured types containing references.  Initially we could simply forbid this, but we'll have to deal with it for serialization eventually.  I haven't run into any problems spawning threads using the new approach, passing messages via copying, etc though.  I expect once I start adding "shared" to the implementation I'll find myself wishing for tail-shared (for performance reasons, in instances where I know the reference isn't shared), so perhaps I should try that soon.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

Please start new threads when changing titles, rather than replying.

Andrei Alexandrescu 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
>
>

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!

[OT} (I'm not to up to date on the latest stuff) is there a way to say that the public interface on a class is thread safe and D doesn't need to do anything special? For that matter, how much of such a contract (given an object reference, there is nothing that can be done via the public interface that can cause threading bugs.) can you enforce vs. how much would that require just trusting the programmer?

Andrei Alexandrescu wrote:
> 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.
>
> b) A serialization protocol. When doing IPC/IMC (M = machine) we'll need to serialize and deserialize objects into streams of bits. deepCopy can't help there.
>
> We could solve both problems with (b) because deserializing a bitcopy will by necessity create a deep copy (you can't serialize a reference/pointer). But I'm still willing to define deepCopy because it seems silly to serialize/deserialize objects if all I want is to pass them to another thread.

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.

The last example doesn't say what type is returned by uniqueCopy().

Thanks, acted upon.

Andrei

Walter Bright wrote:
> The last example doesn't say what type is returned by uniqueCopy().
> 
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency