When chunk hasn't arrived from server yet, the consumer code that is calling Read() will get 0-byte successful reads at rapid pace, until server responds. This means that the consumer is calling the read as fast as it can, millions of times a second, manifesting in 100 % CPU usage. After I inserted a 100 ms sleep in after the line I quoted, CPU usage is back to normal.
This behaviour is discouraged by the Reader interface:
Implementations of Read are discouraged from returning a zero byte count with a nil error
Source
It doesn't say it directly, but it means that Read() is expected to block until it has data to return.
librespot-golang/librespot/player/audiofile.go
Line 104 in 31669e5
When chunk hasn't arrived from server yet, the consumer code that is calling
Read()will get 0-byte successful reads at rapid pace, until server responds. This means that the consumer is calling the read as fast as it can, millions of times a second, manifesting in 100 % CPU usage. After I inserted a 100 ms sleep in after the line I quoted, CPU usage is back to normal.This behaviour is discouraged by the
Readerinterface:Source
It doesn't say it directly, but it means that
Read()is expected to block until it has data to return.