this piece of code here
var (j, more) = <?jobs
if more {
println("received job \(j!)")
} else {
println("received all jobs")
done <- true
return
}
looks analogous to Go code, but there is truly a big difference: The sampleprintln("received job \(j!)")
} else {
println("received all jobs")
done <- true
return
}
code above does not do any blocking. In case the channel is empty it just
exits. In Go the goroutine would be blocked in case the channel were empty.
That goroutine being "lost" then for the scheduler when being blocked is
not a problem in Go as you can easily create some 10k or even 100k
goroutines in Go. But it would be a problem for a language that does not
have some sort of green threads such as Swift where one Swift thread is
represented by one OS thread. So in Swift or some other language with one
thread being represented by one OS thread you would have to revert to
defining some asynchronous callback handler that is invoked when an item is
placed into the channel. And that does not seem to be the case here.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
