Encountered an interesting scenario, that I'm not sure if there's a guarantee for.

static void DestructionHandler(std::shared_ptr<Object> object) {
 while(!object.unique()) {
  sleep(100 ms);
 }
}

...

void something() {
 std::shared_ptr<Object> object = std::make_shared<Object>();
 std::thread destructionHandler(DestructionHandler, object);
 destructionHandler.detach();
}

Is the loop guaranteed to exit, or could the underlying OS code that calls DestructionHandler have an extra reference to the object?

Is the loop guaranteed to exit, or could the underlying library code that calls DestructionHandler have an extra reference to the object (extra copy of the shared_ptr)?

I'm more concerned with: could it possibly be? :)

Though my question was not properly worded using "OS" when the directly underlying caller is probably not the OS but the library implementation (I guess..).

Reading through the standard it seems to be guaranteed, it says that the types of the arguments have to be move-constructible and use what they call "decay copy", so I assume it will have to work at least logically something like copy-constructing to some allocated memory that is passed to the new thread, and then when the library implementation takes over on that thread it will move-construct those objects onto the topmost stack frame in the arguments to the thread handler function.. so I guess it is guaranteed to not hold extra copies.

Though I'm not well versed enough in these rules that I completely understand if there is actually a guarantee that this is how it _will_ work and not just how it _must be possible for it to work_...

and the library is free to do whatever it likes when handing off from an OS thread entry procedure to the thread proc you gave it

That's the main question, if "whatever it likes" includes keeping a copy of the object around for whatever reason, or without reason.

I'm not really concerned with temporary copies as such, just non-destructed copies. I may have been unclear about this.

Another way to write the question:

void ThreadProc(std::shared_ptr<Object> object) {
 object.reset();
 while(true) {
 }
}

void test() {
 std::thread t(ThreadProc, std::make_shared<Object>());
 t.detach();
}

Will the Object whose constructor is called when make_shared creates the object ever have its destructor called?

Again, not sure if it makes sense to even care.. just simpler if it was guaranteed to be destructed.

If not, objects that I really want to always be destructed even when the thread continues to run have to be passed to the thread in another way than the thread arguments.

Seems somewhat senseless for a copy to be kept around somewhere, but that hasn't really stopped anything before :)

Thanks for your replies!
The unique_ptr example is a good one.. that wouldn't work if anything but a move constructor was used obviously.. so depending on template argument handling move-construction for everything on the new thread is probably the only thing that makes sense...

1: Either move or copy all args into the allocated temp storage depending on their template types (still on main thread)

1b: Including the ThreadProc (it's treated specifically by the standard, could be a lambda, std::function etc)

2: Start thread

3: (on thread 2) std::move all args from temp storage in a call to the user-defined ThreadProc

So if that's how it always works for all args then exactly one copy will exist on thread 2 and it will be the arguments to ThreadProc on the stack.

If however the lib implementation was done so that (3) did not properly use move-construction for an argument then there could be a problem.

Thought of another case that must be kept in mind for this, if using a lambda or function wrapper object, namely how operator () is implemented in respect to its arguments (if the thread proc is not directly operator() )

Probably best either way to do like Hodgman says with refs for clearity, or the easiest might be to pass in a unique_ptr<shared_ptr>, to wrap it into something that couldn't possibly be copied anywhere on the way.