Re: sio_write blocking?

On Wed, 10 Feb 2021, Alexandre Ratchov wrote:

> As soon as the hardware consumes buffered samples, space is freed and 
> the same amount could be transmitted with sio_write(). However the code 
> used to transmit the samples may block (eg. network layers may block), 
> and it's difficult to calculate in advance how many bytes could be 
> written without blocking even if we know the amount of free buffer 
> space.

Ahh, ok; that makes sense, thank you!


> The SNDCTL_DSP_GETOSPACE-style interfaces used to be used for two 
> different things:
>
> *snip*
>
> (2) determine how many bytes to write. There's no sndio equivalent for
>     this, the program could use poll() and non-blocking sio_write()
>     which is the standard unix way to implement event loops.

This is the closest to my use case.  I'm working on a real-time audio 
library (aimed primarily at games but also other types of applications). 
It supports both a single- and multi-threaded clients.  The model in 
single-threaded mode is, the client calls an update function periodically 
to refill the audio buffer.  Obviously that function can't block, but also 
wants to avoid starvation.

(Also considering canning the single-threaded mode, as it seems like more 
trouble than it's worth, and it would also obviate this issue.)

In non-blocking mode, can I assume that I can write buf_avail bytes (per 
your above derivation) without an overrun?  Or is a select/poll loop the 
way to go?

  -E