cuse(3) cuse_wait_and_process thread safety

Unitrunker <[email protected]>
Newsgroups gmane.os.freebsd.devel.multimedia
Message-ID <z4gb0FHta2RgVVOgb9R1aetw5B-mIlUajdokq7xGi4thxQVtsIcZkCTsL4o6WzZbgwx4qy6b4LQoc_mulgDaiPV2BvRL08z-tW-eZLipmdc=@unitrunker.net>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.