Instead of pulling values out, have you considered pushing them? E.g. by supplying a delegate that gets called when the asynchronous action completed.
I've always been on the fence about push vs pull when writing libraries of this type. The callback/delegate method is probably more powerful and may reduce latency and context switching, but since the callback happens in the context of the library thread, it exposes the client application to the messiness and problems of managing threads, race conditions, locking and all that. And it can expose the library to performance issues by handing over it's thread to user code which may not return for a long, long time. Plus most of the time I've found that client apps just set a flag and signal a condition variable anyway.
Using a future hides the messiness of threads and race conditions from the user, and it seems that this "Task" paradigm is gaining popularity in a lot of languages.
But a lot of libraries of this sort seem to defer the choice to the user and provide both API's. Mine will have both.
