Hiding executor types and binding nested results

[inbilla]

I really like the design of this library - though I'm looking for two features that I haven't been able to figure out how to achieve with this library.

1. I want to be able to define my interfaces with specific types, i.e. returning a future of a specific type... i.e.. shared_future<value_t>. But it appears the library will not allow me to do this. Instead, it requires me to specify the executor as well?
   Is it possible to avoid exposing the executor details in the return types specified on my interfaces? (The implementation details behind the interface may well use a number of different executors).

2. I want to be able explicitly bind the result of one future, to the result of an encapsulating task.
   I know there was a specific design decision made to avoid doing this implicitly like other implementations - and I like that, but I would also like to be able to explicitly take that path when it makes sense.
   I had toyed with doing this by adding a tag option to the executor (indicating to bind the results together)
   I had also toyed with returning a specific type, i.e. return bind_result(nested_future) to indicate I want the result of that task to be the result of this one.
   Would you consider adding this? or perhaps you have an alternate solution?

Currently, I've wrapped the async method with yet another promise that is fulfilled with a then after the inner task completes, that uses the inline executor to complete the wrapping promise. But it seems wasteful to wrap it in this way. (And this use case also draws your attention to the face that while the inner task might use the default executor, the final returned future is using the inline executor, which brings me back to point 1 - I would like to hide that detail from the interface's type definitions.

All the best, and thanks for your time!

[inbilla]

Actually, I see you have added an "any_executor" to the develop branch.
If I wrap all my executors with this, then all the relevant futures have their executor type erased. This is enough for me.
It might be nice if there is a helper on the basic_future to get a version of the future with the executor type erased, though that may not be easy.

I still would like to see a solution for (2) above though!

[alandefreitas]

Hi.

Yes. I want to implement many changes in this library, but I haven't had much time (like zero time over the last year). The original idea was to implement a layer based on futures and promises that would put the futures/promises interfaces, sender/receivers, asio, and coroutines in harmony with little effort because you could only implement a valid executor and access all these APIs. I have been refactoring the library locally to achieve these goals and ensure it's tsan-safe, but I never got to complete it. It's hard to get continuations right in a way that's tsan-safe, and all libraries I tested failed with tsan. Even boost.

1. Each future type has a type and I believe there's something like get_executor(). This might be in a different version than the most recent semver version that was released.
2. I had a local solution for unwrapping the future similar to what you proposed, but it never got to the repository. This concept of a futures::scoped_executor whose types get peeled when you call then. If you have an initial future using some executor E, a scoped_executor<inline_executor, E would allow us to do things like pushing a continuation in the inline_executor that would unwrap the future for the next task back in E. Of course, there was an API to simplify that. This also never got pushed.

It might be nice if there is a helper on the basic_future to get a version of the future with the executor type erased, though that may not be easy.

Yes. I don't know how hard this would be. The usual problem with an eager future is the address for the result needs to be stable once the task starts.

[inbilla]

Thanks for responding!
I totally understand not having the time to put into the project. Thanks for taking the time to respond.
Honestly, I'm really enjoying the current published state of the develop branch. What kind of issues is tsan raising? do the refactors you're attempting affect the overall API much?

[alandefreitas]

Honestly, I'm really enjoying the current published state of the develop branch

Yes. I even used it in some other projects. Having futures attached to a thread pool instead of launching a new thread for each future is already useful enough for many things.

What kind of issues is tsan raising?

Usually, some edge cases that trigger tsan in continuations. I've experimented with other libraries, but they all had the same issues with tsan.

Most don't even test their libraries with tsan because they're too old. After std::future got into C++11, most of the work has been going into competing models: asio, coroutines, S/R, etc... So I just found out about these issues when I tried to put these new models into a new API that looks like std::future.

do the refactors you're attempting affect the overall API much?

Not really. It's mostly about expanding the API or fixing these tsan issues. The only foreseeable breaking change would be C++20 at some point because the meta-programming and polyfills are becoming unmanageable.