-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sbitx_sound.c: sound_thread_start function: possible code 'smell' #38
Comments
i wrote that to allow the first thread to open up the alsa device before the loopback is initialized. what alternative do you suggest? |
Note: Any of these functions could potentially fail. Best practice would check the return codes (if any). 3). In the thread that must wait for the alsa device to be opened before the loopback is initialised, wait on the condition variable
note: pthead_cond_wait unlocks and locks the mutex as required.
5). Correctly the threads, condition variables should be closed (finalisation) however everything should be cleaned up when the program exits.
|
I agree this is good solution. For less code verbosity, an atomic variable and spinlock could be used too. G8KIG, could you make a PR? I could review it. |
It's already done and tested in my fork. I will do a PR for everything when things settle down. |
Cool! Just realized about your fork. |
Can you clarify the purpose of the sleep(1) in the sound_thread_start function.
If this is attempting to get the sound_thread function running before loopback_thread runs it will not work as intended.
This is because there are a large number of threads potentially runnable as well as sound_thread.
Using sleep or any of the related functions is always a code 'smell'
The text was updated successfully, but these errors were encountered: