I'm not really used to callback APIs (except glut, which I like to pretend never happened) and have traditionally used futures or some kind of thread-pool mechanism for asynchrony in my code. As such, I don't really understand how this works.
So I've got a "kick-off" endpoint:
void doneHandler(SomeLibraryObjectAsync *caller, other_args)
{
//write to some static memory somewhere.
delete caller;
}
void doStuff()
{
SomeLibraryObjectAsync* task = new SomeLibraryObjectAsync;
task.GoAndCallThisWhenDone(doneHandler);
}
This is obviously highly pared-down, but the problem still rears its ugly head -- how can I safely delete the async object without a blocking wait on the main thread? The delete call in the handler should take care of it, but as far as I can tell there's no way I can know if that delete call is safe, because the object itself is above it in the stack, and without looking at the source code (if it's even available, which in my case it's not) I have no way of knowing whether it's safe to destroy at that moment.
Is it just assumed that all callback-based APIs ensure safe destruction when their last callback runs? Is there some magical "delete but don't call the destructor until the object I want to destroy gets popped off the callstack-but-not-quite-RAII" thing I've never heard of in C++?
Perhaps I've just drunk the RAII kool-aid so much I can't even reason around objects with non-deterministic lifetimes.