On Mon, 07 Mar 2011 09:45:02 +0100 Ivan Le Lann <ivan.lelann@free.fr> wrote:
I don't think that this is enough to prevent surprises. If someone does
thread t( f, x );
where x is an integer, the thread would receive a shared copy of x. The user would need to explicitly call the copy constructor with a second argument of true to avoid that.
You'd think so, but so long as that thread class takes the integer parameter as either a constant reference or by value, or is the only one thread accessing it if it's passed by non-constant reference, that's not the case.
I'm not sure I understand why you say that t does not get a shared copy. Anyway what seemed obvious to me with current impl is that block below can either leak or double destruct x data. Am I wrong?
void f (integer) {} // by value ... { integer x = 42; async ( f, x ); async ( f, x ); }
It depends on the implementation of async. If async takes x as a const reference, then it *would* be shared between them, but presumably they would finish with it before 'f' exits... otherwise, passing a local to them is a client-code design bug. If it's a non-const reference, and both calls make changes to it, that's another client-code bug that the library can't do much about. If async passes them by value, then there's no trouble. Unless you explicitly tell the library to use CoW on external objects, it will deep-copy them, so each call to async will get its own storage. So if the client code is written to avoid bugs, the way that it would have to be with any kind of object, XInt will do the right thing. -- Chad Nelson Oak Circle Software, Inc. * * *