[Bug 797289] dispatch write never ends

[GStreamer (GNOME Bugzilla)]

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

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slomo at coaxion.net

--- Comment #3 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Göran Jönsson from comment #2)
> 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.  

Ok so that needs a comment and reasoning in the code.

In summary that means that a) when called from appsink we always send as much
as we can, and b) when called from the idle callback or the watch callback we
would first queue another idle probe.

> 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 ?

See bottom of do_send_data(). You want to use priv->watch_context here
unconditionally.

> 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.

Which threads do you mean? There's the appsink thread, which we don't have
access to. And then there's the thread to which priv->watch_context belongs and
that's the one we can make use of here.

That's the thread that also calls the watch callback so probably exactly the
one you want?

You can check if you're called from that thread by g_main_context_is_owner()

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