3 ms·

Thank you for such extended answer. 1. I would politely disagree with Go channels are efficient. If they would be efficient, they would be actively used intern

by tandr 6y ago

Thank you for such extended answer. 1. I would politely disagree with Go channels are efficient. If they would be efficient, they would be actively used internally as a synchronization primitive. I don't remember seeing external libraries using it past notification mechanism of "it is done" kind either. There would be some nifty tricks possible if cost of channels is much lower, or compiler would be able to use some "very light" channels if it sees it is possible (not sure if it even theoretically possible, but I am not an CS theory guru...) 2. That's kind of unfortunate, I would prefer if error is requested, just return an error err := ch <- data_to_send vs ch <- data_to_send which might panic. But looks like neither of languages allow this. I proposed the syntax above to Go, but it was rejected. 3. That's nice. Is there an error to catch if needed? err := close(ch)

tandr 6y ago
Silly me - the syntax that I proposed was the second one err := close(ch) to handle case when you don't want a panic on closing of closed channel. The first one was discussed on golang-nuts, but it died there.
- ylluminate 6y ago
  Would highly suggest you pop onto Discord (https://discord.gg/vlang https://discord.gg/vlang) to chat in #concurrency about this further...
UweKrueger 6y ago
1. There are some principle limits to take into account: Channel operations involve task switches - especially on unbuffered channels. How expensive these are depends on the scheduler, but basically they are expensive on all operating systems. Other synchronization primitives (like mutexes, semaphores, atomics) can be implemented in a way that the scheduler is not involved when no (long) blocking is needed (futex, spin-locks, ...). The Go people took the path to implement their own scheduler, which is highly optimized for channel operations, on top of the OS (similar to a virtual machine). So, they don't use OS-threads or OS-mutexes. This does result in better channel performance, but still there are task switches. And this approach has other drawbacks concerning C interoperability. V sticks to OS-threads and the OS-scheduler (and not re-implementing these could be called "lightweight"). This means better C interoperability but channel operations are even more expensive. For this reason I've also implemented `shared` objects into the V core language as a more efficient way of sharing data (see also https://github.com/vlang/v/blob/master/doc/upcoming.md#variable-declarations https://github.com/vlang/v/blob/master/doc/upcoming.md#varia...): shared x := ... go f(shared x) lock x { // modify x } rlock x { // read x } 2./3. Syntax considerations should be consistent within the whole language. As @illuminate has already pointed out we discuss these things on discord (https://discord.gg/vlang https://discord.gg/vlang). There's also a channel #syntax.

by tandr 6y ago

tandr 6y ago

Silly me - the syntax that I proposed was the second one err := close(ch) to handle case when you don't want a panic on closing of closed channel. The first one was discussed on golang-nuts, but it died there.

ylluminate 6y ago
Would highly suggest you pop onto Discord (https://discord.gg/vlang https://discord.gg/vlang) to chat in #concurrency about this further...

UweKrueger 6y ago

1. There are some principle limits to take into account: Channel operations involve task switches - especially on unbuffered channels. How expensive these are depends on the scheduler, but basically they are expensive on all operating systems. Other synchronization primitives (like mutexes, semaphores, atomics) can be implemented in a way that the scheduler is not involved when no (long) blocking is needed (futex, spin-locks, ...). The Go people took the path to implement their own scheduler, which is highly optimized for channel operations, on top of the OS (similar to a virtual machine). So, they don't use OS-threads or OS-mutexes. This does result in better channel performance, but still there are task switches. And this approach has other drawbacks concerning C interoperability. V sticks to OS-threads and the OS-scheduler (and not re-implementing these could be called "lightweight"). This means better C interoperability but channel operations are even more expensive. For this reason I've also implemented `shared` objects into the V core language as a more efficient way of sharing data (see also https://github.com/vlang/v/blob/master/doc/upcoming.md#variable-declarations https://github.com/vlang/v/blob/master/doc/upcoming.md#varia...): shared x := ... go f(shared x) lock x { // modify x } rlock x { // read x } 2./3. Syntax considerations should be consistent within the whole language. As @illuminate has already pointed out we discuss these things on discord (https://discord.gg/vlang https://discord.gg/vlang). There's also a channel #syntax.