Skip to content
This repository has been archived by the owner on Mar 7, 2024. It is now read-only.

mod_audio_fork - need of multiple locks/mutexes #128

Open
anshumanr opened this issue Aug 10, 2023 · 2 comments
Open

mod_audio_fork - need of multiple locks/mutexes #128

anshumanr opened this issue Aug 10, 2023 · 2 comments

Comments

@anshumanr
Copy link

Hi @davehorton
We are using mod_audio_fork module. I was going through the code and could not understand the need to acquire/lock multiple mutexes in func fork_frame()

  1. mutex part of variable type struct private_data is acquired at lws_glue.cpp#L530.
  2. mutex part of class AudioPipe and used to access the audio buffers is acquired at lws_glue.cpp#L541

Also, this callback is invoked from func switch_core_session_read_frame() in switch_core_io.c inside a lock (bug->read_mutex). So I could not understand the need to acquire multiple mutexes in fork_frame().
Could you please throw some pointers as to what I missed?
Thanks.

@davehorton
Copy link
Collaborator

please be patient as you are asking for a detailed investigation and description of the code. If possible I will get to this.

@anshumanr
Copy link
Author

I seem to have found the missing piece of my understanding.

  1. struct private_data is accessed in 2 different threads - fork_frame() and fork_session_cleanup(). I believe they can be invoked by FS in 2 different threads.
  2. same for object of type AudioPipe. It is accessed in fork_frame() and in AudioPipe::lws_callback() for case LWS_CALLBACK_CLIENT_WRITEABLE. Need to check what that case means.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants