<html><head>
<style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head>
<body><div>Le mardi 20 février 2024 à 16:22 +0000, Will McElderry via gstreamer-devel a écrit :</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> </div><p>Hi All,</p><div> </div><p>I'd like to understand more about the locks and threads in GStreamer.</p><div> </div><p>Can anyone point me to some docs or code to read to help get a grip on it all?</p><div> </div><p><br> </p><div> </div><p>I've read <a href="https://gstreamer.freedesktop.org/documentation/additional/design/dynamic.html?gi-language=python">this</a> that mentions it's important to understand about the application and streaming threads, and <a href="https://gstreamer.freedesktop.org/documentation/additional/design/events.html?gi-language=python">this</a> that mentions 'the STREAM_LOCK' in various places. I think I've read a few other pages that reference these topics too, but haven't found anything that gives a good grounding about what's behind the design.<br> </p><div> </div><p>I've definitely fallen foul of issues from not understanding enough of these low-level details while trying to move up the learning curve and use signals to trigger actions. Sometimes I've had lock-ups immediately every time and sometimes it has taken a few thousand runs to spot the impact of a race condition, so I'd love to get clarity!</p></blockquote><div><br></div><div>You may also want to review this one, as its about the mechanism in place for <a href="https://gstreamer.freedesktop.org/documentation/additional/design/MT-refcounting.html">thread safety</a>. You can get a visual overview of what a <a href="https://gstreamer.freedesktop.org/documentation/application-development/advanced/threads.html?gi-language=c#when-would-you-want-to-force-a-thread">streaming thread</a> is. From there, I must admit the doc is a bit unclear, but each time a streaming thread activates (that data/serialized events is being pushed or pulled), each visited pads get their stream_lock (a recursive mutex) held. This ensure that no one can modify the links and pad state while data is flowing. As a side effect, you have to take great care of what you are doing when you are being called back from one of these threads, as you may endup in impossible situations like deadlock due to this implicit locking.</div><div><br></div><div>Nicolas</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div> </div><p><br> </p><div> </div><p>Thanks for reading and all the help so far!</p><div> </div><p>Will.</p><div> </div></blockquote><div><br></div><div><span></span></div></body></html>