Adding channel LCO #2265
Adding channel LCO #2265
Conversation
- the API is modelled after the channel type of the Go language
- add more diagnostics - add tests - flyby: fix queue component
- flyby: fixing issue in HPX causing actions returning future<void> swallowing exceptions - fixed sequencing issue during channel::close
|
|
||
| { | ||
| hpx::lcos::local::channel<int> c; | ||
| hpx::lcos::local::channel<> done; |
There was a problem hiding this comment.
why do the types not match in the function signature and here?
There was a problem hiding this comment.
They could match. receive_channel and send_channel are constructable from channel, but they limit its use to one end of the communication. Thus this would work as well:
void do_something(
hpx::lcos::local::channel<int> c,
hpx::lcos::local::channel<> done)
{ ... }
There was a problem hiding this comment.
I guess what I wanted to say is that this information (implicit conversion and purpose) is missing from the documentation.
There was a problem hiding this comment.
The docs are currently sketchy at best anyways ;-)
There was a problem hiding this comment.
Right, so why not make them good from the start ;)?
- synchronous version is now called channel::get_sync
…n of channel<void> et.al.
| { | ||
| return std::make_pair(f.get(), true); | ||
| } | ||
| return std::make_pair(T(), false); |
There was a problem hiding this comment.
This is swalloing exceptions, isn't it?
There was a problem hiding this comment.
Yes, this is used to flag the end of a range, so it ignores the exceptions. This is yet another argument in favor of making the iterators lazy.
|
@sithhell How should we proceed here? Is this ok to be merged? |
|
@hkaiser I am not sure, how should we resolve the remaining open points? |
|
@sithhell The only thing I can try to work on is to make the iterators lazy. Everything else requires decisions beyond the scope of this PR. |
|
Some more investigation has shown that implementing asyncronous iterators requires building a completely new infrastructure which is way beyond the scope of this PR. Thus I'd like to go ahead with this as is now. If the current iterator design is too controversial I'd be happy to remove it alltogether for now. |
|
[07:05] heller: regarding channel ... should we just ditch the iterator? do you have a specific use case? |
|
Once #2276 has been merged we can change the interfaces for the |
|
This PR is ready to be merged now. The channel API has been adapted to the new launch policies. |
| hpx::apply(&sum, std::vector<int>(s.begin() + s.size()/2, s.end()), c); | ||
|
|
||
| int x = c.get_sync(); // receive from c | ||
| int y = c.get_sync(); |
There was a problem hiding this comment.
The two lines above don't look right. Why don't you use launch policies there?
There was a problem hiding this comment.
Sorry, I forgot to change the example.
This PR adds two new LCOs: local::channel and channel (one for local only operation, the other is a component). Both expose a similar interface which is aligned with the channel object known from the Go language.
This is meant to be a basis for discussions aiming at finding the best possible API for such a facility, so please comment.