Range Interface

[StephanDollberg]

Hi,

I am wondering whether you have put any thought or what you think about providing a range interface via fake-iterators/begin/end?

So that we could use the channel as one can use it in a Go loop:

for(auto&& elem: channel) {
    // do stuff
}

I quickly wrote something together using boost::iterator_facade and while it seems to work it's pretty hacky.

Cheers,
Stephan

[ahorn]

Could I ask you in what kind of application you are currently using cpp-channel?

[StephanDollberg]

@ahorn Currently, I am not using it in any real application. I am just getting to know Go and thought that something channel like would be interesting in C++ and that's how I found cpp-channel.

[ahorn]

Cool. This doesn't sound too unfamiliar :)

I started this repository because I wanted to find out how far one gets by using the new C++11 concurrency-related features in implementing Go-style channels. In doing so, I've come to the conclusion that C++11 condition variables and locks are probably not the way to go because the operations on channels lead to many context switches, and the overhead for this is quite high.

A different (and faster implementation) may be possible by using coroutines. It my understanding that there is some discussion in the standard committee for adding some coroutine-like features to the language. In the meantime, however, it would be worthwhile to ask Oliver Kowalke if it would be okay to take his context library and use it directly without the other parts of boost. I see several benefits of using coroutines: (1) easier reasoning about scheduling, (2) more efficient handling of OS context switches (3) full featured cpp::select statements.

[StephanDollberg]

Yeah, that makes sense. If I got it right then the standard coroutines are quite on track.

Using boost::coroutines one would still need some kind of synchronization to use them in a multithreaded context or do you plan to write your own ones based on boost::context?

[ahorn]

It depends; I think it depends how boost::coroutine work. Would you feel comfortable implementing a prototype that uses boost::coroutine so we could take a look at the design space?

[StephanDollberg]

I will have a look at boost::coroutine and see what it can do. So far I have only used the boost::asio wrapper.

[ahorn]

Cheers.

[StephanDollberg]

So, I had a look at boost::coroutine. You can indeed pass coroutines from thread to thread as long as there is no thread-local storage involved [1]. Still, I think they are more meant for single threaded cooperative scheduling (e.g.: to implement goroutines) [2]. I don't know/already forgot whether this is in line with the functionality of what is planned for the standard coroutines. Maybe it could still be somehow used on the "select" side.

During my research about how Go implements the channels/select I found this link. They are basically also using a lock/lock-free ringbuffer for the communication channel.

In case, you didn't know them yet, I would check out the links as I think that they are quite interesting.
Hope this helped you a bit.

[ahorn]

This is helpful. Thank you. Are you planning to implement anything?

[StephanDollberg]

Not for now.