[Bug 721807] souphttpsrc: expose SoupSocket

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=721807
  GStreamer | gst-plugins-good | unspecified

--- Comment #17 from Alban Crequy <alban.crequy at collabora.co.uk> 2014-01-16 16:04:11 UTC ---
(In reply to comment #13)
> Out of curiosity, would it be possible to do something with the souphttpsrc
> thread instead? (e.g. move the thread to a certain cgroup) - you should be able
> to do that using the STREAM_STATUS messages then I think.

- The thread-level granularity of cgroups is annoying.

- Even though it should be possible to shape *egress* traffic with cgroups, we
can't shape ingress traffic with cgroups because of the reason in Comment #8.

> (Sorry to be so insistent, I just dislike the idea of exposing this stuff)

No worries, I would like to hear if there is a better way :)

(In reply to comment #16)
> And even just exposing the addresses as mentioned in comment 11 and comment 12
> is not really useful. It's never threadsafe, souphttpsrc could decide at any
> moment to restart the connection.

It is not critical if there is some delay between a new libsoup connection and
installing new traffic control rules with the correct 5-tuple (ip/port
src/dest, protocol). The worst which can happen is that the first incoming
packets are handled with the wrong rate.

In theory it should be possible to implement this without delay: get the
5-tuple and install the new TC rules before sending anything on the socket. But
in practice, it might be easier to get the information serialised from the gst
bus (or GObject property notification?) and send it asynchronously with a D-Bus
message to the TC daemon.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.