Re: cuse(3) cuse_wait_and_process thread safety

On Wed Feb 18, 2026 at 2:14 PM CET, Unitrunker wrote:
> I'm posting this to the multimedia list because virtual_oss is the
> main consumer of cuse(3).
>
> Looking over the documentation for cuse_wait_and_process, cuse.3
> reads:
>
> int cuse_wait_and_process(void) This function will block and do event
> processing. If parallel I/O is required multiple threads must be created
> looping on this function. This function returns 0 on success or a
> negative value on failure. See CUSE_ERR_XXX for known error codes.
>
> My concern lies in the suggestion to provide parallel I/O by having
> multiple threads call this function.
>
> I'm writing this message to get some extra eyes on this and maybe some
> feedback.
>
> cuse_wait_and_process processes exactly one I/O operation and returns.
> No more and no less.
>
> If the cuse driver is holding two pending IO operations for two
> different cuse devices, it isn't so important as to which goes first.
> They can race and not interfere with each other.
>
> However, if there are two or more pending IO operations - such as two
> reads or two writes to the same device and each operation is picked up
> be a different thread at more or less the same time, the second IO
> operation might finish before the first. In the case of virtual_oss,
> this might cause out-of-order buffering of audio data.
>
> Today, virtual_oss creates four threads per virtual device (see
> "create_threads" in usr.sbin/virtual_oss/virtual_oss/main.c). I see a
> potential problem.
>
> I'll be very happy if this turns out to be a non-issue.
>
> Regards,
> Rick

I'm the maintainer of virtual_oss. To be fair, I don't know what was
HPS's (RIP) rationale for giving each device 4 threads, so I'm not sure
how to answer this question. Have you run into the problem you described
since you sent the email?

Christos