Add lcos::local::one_element_channel #2631
Conversation
hkaiser
commented
May 15, 2017
hkaiser
commented
- refactored local channel implementation
- channel::set is now optionally asynchronous
- adding asynchronous iterator support to channel
- adapt specializations of coroutine_traits to latest changes - properly propagate exceptions through co_await - flyby: fix co_await future<future<T>> - flyby: change return to co_return where appropriate
hkaiser
force-pushed
the
channel_one_element
branch
from
01e4a6d
to
e47bef3
Compare
- refactored local channel implementation - channel::set is now optionally asynchronous - adding asynchronous iterator support to channel
hkaiser
force-pushed
the
channel_one_element
branch
from
e47bef3
to
497d413
Compare
hpx/lcos/local/channel.hpp
Outdated
| { | ||
| if (push_active_) | ||
| { | ||
| // error! |
There was a problem hiding this comment.
Can we return an exceptional future here?
There was a problem hiding this comment.
Right, that was the plan ;)
hpx/lcos/local/channel.hpp
Outdated
| { | ||
| if (pop_active_) | ||
| { | ||
| // error! |
There was a problem hiding this comment.
Can we return an exceptional future here?
hpx/lcos/local/channel.hpp
Outdated
|
|
||
| void cancel(boost::exception_ptr const& e) | ||
| { | ||
| if (pop_active_) |
There was a problem hiding this comment.
this should be done inside the lock as well to avoid races.
There was a problem hiding this comment.
This is called while the lock is being held. I'll make it explicit.
hpx/lcos/local/channel.hpp
Outdated
|
|
||
| private: | ||
| friend class channel_iterator<T>; | ||
| friend class receive_channel<T>; |
There was a problem hiding this comment.
Why does it need to be friends with itself?
There was a problem hiding this comment.
Right, copy&paste error.
| {} | ||
| receive_channel(one_element_channel<void> const& c) | ||
| : base_type(c.get_channel_impl()) | ||
| {} |
There was a problem hiding this comment.
wouldn't a constructor taking a channel_base const& be enough?
| : base_type(c.get_channel_impl()) | ||
| {} | ||
| send_channel(one_element_channel<T> const& c) | ||
| : base_type(c.get_channel_impl()) |
There was a problem hiding this comment.
wouldn't a constructor taking a channel_base const& be enough?
| {} | ||
| receive_channel(one_element_channel<T> const& c) | ||
| : base_type(c.get_channel_impl()) | ||
| {} |
There was a problem hiding this comment.
wouldn't a constructor taking a channel_base const& be enough?
There was a problem hiding this comment.
No for two reasons:
- in that case a
receive_channelwould become constructible from asend_channel, for instance - all channel classes are non-publicly derived (using
protectedderivation) fromchannel_base
|
Hmm, I'm not a big fan of that, that makes a little awkward to extend.
Could we do it the other way around, that is have an explicit operator in
the various channels?
|
Of what? Could you elaborate, please? |
That we essentially have to list all channel implementations in the ctor of |
I don't have a better solution. Besides, being explicit is always better than relying on implicit conversions. |
