Skip to content

soup: move libsoup session into its own thread

Daniel Kolesa requested to merge q66/gstreamer:soup-thread-safety into main

Starting with libsoup3, there is no attempt to handle thread safety inside the library, and it was never considered fully safe before either. Therefore, move all session handling into its own thread.

The libsoup thread has its own context and main loop. When some request is made or a response needs to be read, an idle source is created to issue that; the gstreamer thread issuing that waits for that to be complete. There is a per-src condition variable to deal with that.

Since the thread/loop needs to be longer-lived than the soup session itself, a wrapper object is provided to contain them. The soup session only has a single reference, owned by the wrapper object.

It is no longer possible to force an external session, since this does not seem to be used anywhere within gstreamer and would be tricky to implement; this is because one would not have to provide just a session, but also the complete thread arrangement made in the same way as the system currently does internally, in order to be safe.

Messages are still built gstreamer-side. It is safe to do so until the message is sent on the session. Headers are also processed on the gstreamer side, which should likewise be safe.

All requests as well as reads on the libsoup thread are issued asynchronously. That allows libsoup to schedule things with as little blocking as possible, and means that concurrent access to the session is possible, when sharing the session.

Fixes #947 (closed)

Edited by Daniel Kolesa

Merge request reports