it's *not* 'Like Go channels over the network' about libchan

[pkieltyka]

truth

[stevvooe]

@rade When one waits on a libchan receiver, the caller blocks until a message is received. Ignoring issues with the network, this plays the analog of a blocked channel. This is one of the building blocks of channel-based synchronization in Go that are mirrored by features in libchan.

What features are missing from libchan that could make the tagline true? Or are you just interested in resolving a minor semantic inconsistency?

[dmcgowan]

@stevvooe something still needs to be done to resolve this issue. Either documentation needs to be clear that the primitive libchan channel does not have go semantics, libchan protocol needs to be updated to define synchronization on the primitive channel, or an example needs to be added to highlight using libchan for synchronization such as you suggested.

Right now I think adding an example makes sense, I am still not sold one way or the other about having the libchan channels be synchronized. It adds complexity and in many cases it might not be desired to use (even if its cleaner semantically). Now that others are integrating and using libchan, I will let this issue be a place to discuss use cases and needs around synchronization and go semantics.

[rade]

@stevvooe

What features are missing from libchan that could make the tagline true? Or are you just interested in resolving a minor semantic inconsistency?

Go channels have a user-definable, precise capacity.

Go channels support blocking 'send'.

Go channels support 'select'.

[stevvooe]

@rade Thank you for the feedback!

Regarding blocking send and channel capacity, I not sure how we could faithfully implement these over the network and keep things simple. We may want to add a "differences from Go channels" section and call these out specifically.

Regarding select, I've filed #76. Thats a good idea and generally useful.

[rade]

Regarding blocking send and channel capacity, I not sure how we could faithfully implement these over the network and keep things simple.

I don't think you can.

[rade]

So I'm guessing libchan 'send' semantics is more like go's async send, i.e. it's really

select {
    case ch <- msg:
    default:
}

i.e. it's non-blocking and it can lose messages (even in the absence of network/process failure). Right?

It would be quite important to state that in the docs.

Also note that if there was a blocking send, or a guarantee of no message loss in the absence of network/process failure, then a faithful implementation of select would require distributed consensus.

[dmcgowan]

Adding this to 0.2.0 along with updated protocol. The semantics should be clearly defined along with the differences between Go channels. The 0.2.0 protocol PR attempts to lay out it more clearly, the README needs quite a bit of attention still.

[danilomo]

Using go channels with location transparency is impossible for two reasons:
1 - it is not implemented in the core language
2 - You cannot override the "->" operator. If I WAS the responsible person for the language's design, there would be a way to implement some interface that allows you to use a custom object as a channel, indistinctly. Something similar to implementing iterable objects that can be looped through a foreach, in any language.

Therefore I don't see a point in this issue. Having channels with location transparency isn't achievable, therefore something like libchan is the best we can have.

Please someone correct me if I'm wrong.