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