work item variant execution should support arbitrary return types

[sithhell]

Currently, the return type of a work_item variant execute function supports the following return types:

• hpx::future<T>
• allscale::treeture<T>
• hpx::unused_type

The last return type is important for performance optimizations. The process variants seldomly spawn other work items asynchronously, as such, it is beneficial for performance reasons, to avoid the allscale::make_ready_treeture(...) return in such cases. Even a ready treeture is associated with some overheads.

It should be possible, to support arbitrary, non treeture return types, like void instead of hpx::util::unused_type or int.

[destructor64]

We are currently trying to remove calls to allscale::make_ready_treeture in this context and replace the return type with hpx::unused_type

[sithhell]

This is now possible. Please see https://github.com/allscale/allscale_runtime/blob/master/examples/fibonacci.cpp#L107-L110

as an example.

[destructor64]

This has been implemented in the compiler with commit 0298fffc3b7853a1178a219e6d6a67742b0dbe85. We are now returning allscale::unused_type (which is an alias for hpx::unused_type)

We also already updated the compiler pointer in the external integration test job to reflect this.

[sithhell]

Am 05.12.2017 3:23 nachm. schrieb "peterz-dps" <[email protected]>: This has been implemented in the compiler with commit 0298fffc3b7853a1178a219e6d6a67742b0dbe85. We are now returning allscale::unused_type (which is an alias for hpx::unused_type) We also already updated the compiler pointer in the external integration test job to reflect this. Excellent! Out of curiosity, since `void` would be possible too, is there any specific reason to go for unused instead? I don't think it matters overall... — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADRlwxL4fdlxvosWdg2oTzZoAmJAtM4ks5s9VH2gaJpZM4QyEvw> .

[destructor64]

The reason is, that we started implementing this change before that was possible. I implented this based upon the mail you sent to Herbert once regarding this situation.