41–50 of 54 posts
I suppose "choose" was used for multiplexing channel reads to avoid clashing with select(2) ( ) on BSD/POSIX systems..?
Earlier quoted context omitted.
Is this how the term OO got degenerated? In Communicating Sequential Processes, you only communicate via messages (C) & the processes (P) sequentially (S) run to completion. Go is not CSP. It is fair to say it was inspired by CSP. Go has a preemptive scheduler, and passing shared memory references is idiomatic and at times unavoidable.
Go-the-language does not have a preemptive scheduler, just guarantees about how various means of synchronization interact. In fact, Go-the-implementation is only partially preemptive, I believe: in addition to calls into the runtime, calling any function can now be a scheduling event. But if you have a tight loop with no function calls (just arithmetic, perhaps), that goroutine will not yield control. A true preempti…
[edit: hmm. Possibly I've mis-parsed that.]
Earlier quoted context omitted.
it's CSP as extended by golang, i.e. with channels rather than named processes.
Is this how the term OO got degenerated? In Communicating Sequential Processes, you only communicate via messages (C) & the processes (P) sequentially (S) run to completion. Go is not CSP. It is fair to say it was inspired by CSP. Go has a preemptive scheduler, and passing shared memory references is idiomatic and at times unavoidable.
I have a theory that there exists no software engineering term that is unambiguously understood by all language communities to be the same thing. If there is one, it won't be for long.
Another recent fun one: "Continuation". Used to mean something very specific in the programming language theory community, it is now nearly indistinguishable from "thread" in many communities.
Earlier quoted context omitted.
Is this how the term OO got degenerated? In Communicating Sequential Processes, you only communicate via messages (C) & the processes (P) sequentially (S) run to completion. Go is not CSP. It is fair to say it was inspired by CSP. Go has a preemptive scheduler, and passing shared memory references is idiomatic and at times unavoidable.
"Is this how the term OO got degenerated?" I have a theory that there exists no software engineering term that is unambiguously understood by all language communities to be the same thing. If there is one, it won't be for long. Another recent fun one: "Continuation". Used to mean something very specific in the programming language theory community, it is now nearly indistinguishable from "thread" in many communities.
Compare to state of affairs in medicine, as an example.
Finally, something that purports to have Go-style concurrency that actually provides the equivalent of select{}! Lots of things just provide chans, which are fancy thread-safe queues and are fairly easy to implement. Getting select{} right is the tricky (and powerful) part.
Finally, something that purports to have Go-style concurrency that actually provides the equivalent of select{}! Lots of things just provide chans, which are fancy thread-safe queues and are fairly easy to implement. Getting select{} right is the tricky (and powerful) part.
Finally, something that purports to have Go-style concurrency that actually provides the equivalent of select{}! Lots of things just provide chans, which are fancy thread-safe queues and are fairly easy to implement. Getting select{} right is the tricky (and powerful) part.
Earlier quoted context omitted.
Go-the-language does not have a preemptive scheduler, just guarantees about how various means of synchronization interact. In fact, Go-the-implementation is only partially preemptive, I believe: in addition to calls into the runtime, calling any function can now be a scheduling event. But if you have a tight loop with no function calls (just arithmetic, perhaps), that goroutine will not yield control. A true preempti…
Not so. http://golang.org/doc/go1.2#preemption [edit: hmm. Possibly I've mis-parsed that.]