Golang - do libraries need to be non-blocking?

Question

My understanding is that non-blocking web servers (node.js, eventmachine, tornado) can grind to a halt if they make a call to a blocking library. Is this true for Golang as well? If one goroutine gets blocked, is another one automatically given access to the CPU, or do they have to wait for the blocked goroutine to 'yield'? If it is the former, then libraries don't need to be non-blocking, do they? I ask because I haven't seen any Redis/Mongo libraries that explicitly state that they're non-blocking.

Answer 1

My understanding is that non-blocking web servers (node.js, eventmachine, tornado) can grind to a halt if they make a call to a blocking library. Is this true for Golang as well?

No it isn't. Go routines will yield on IO or the runtime will create new OS threads as necessary.

If one goroutine gets blocked, is another one automatically given access to the CPU

Yes it is - go routines yield on any sort of IO or channel communication.

or do they have to wait for the blocked goroutine to 'yield'?

No they don't.

If it is the former, then libraries don't need to be non-blocking, do they? I ask because I haven't seen any Redis/Mongo libraries that explicitly state that they're non-blocking.

No libraries (or Go code in general) don't need to be non blocking which makes them much easier to write and maintain. This is a major plus point of Go in my opinion. The runtime does the clever bit running 1000s of go routines and you just write simple imperative code.