[Bug 797289] dispatch write never ends

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Oct 16 10:35:53 UTC 2018


https://bugzilla.gnome.org/show_bug.cgi?id=797289

--- Comment #2 from Göran Jönsson <goran.jonsson at axis.com> ---
You wrote:
"I don't understand this part of the code. Why do you care if there's a current
GSource running on this thread and calling into us? There will be one also in
the case of the idle source above and the message directly being sent without
queue, there will be one if the message was sent from the queue. There might
only be none if we're called directly from the appsink callback or not? "

Answer:
I want a difference between when calling from appsink (no source) then there
are
no problems. But when called from dispatch_write or 
the new idle source we just wanted short executions so dispatch read also can
be called. The case when the idle source is sending directly without queuing
haven't I think of at all. But when doing that I can't see that there are any
special thing to consider.  

You wrote:
"g_source_get_context() why? Shouldn't we attach to the main context of the
rtsp-server (from where the connection is used) here? "

Answer:
The two context I have consider when doing this patch is the 
* main context , but since there are a mutex involved I don't want to run this
on main thread.
* The context that handle dispatch write and dispatch read.
Is main context of the rtsp-server a third ? How can I get access to it ?

General:
I just want to say that this is just a suggestion to solve the problem.A
proposal to start a discussion.

I think a better solution is to detect that on_message_sent is executed by
dispatch write and there are more data to send. And then handover the execution
to the threads that normally send rtp/rtcp. But I can't find a solution like
that.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list