[Bug 785684] rtspconnection: add API to send messages without blocking

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Oct 24 13:59:28 UTC 2017


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

Branko Subasic <branko.subasic at axis.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |branko.subasic at axis.com

--- Comment #17 from Branko Subasic <branko.subasic at axis.com> ---
(In reply to Tim-Philipp Müller from comment #10)
> As I already told Anila, I don't understand this whole nonblocking business
> here.
> 
> To me it seems like there are two separate concerns: a) something about
> non-blocking, not sure what that is ultimately supposed to fix, b) write
> bufferlists/vectors more efficiently.
> 
> The while loop in this patch looks to me like it does the exact same thing
> as a blocking send_messages call would do.


You are right, the actual socket is in non-blocking mode, and
g_socket_set_blocking() decides whether gio will behave blocking or not. So
there is no need to call g_socket_set_blocking().

Regarding the while loop, g_socket_send_message() behaves in a similar way. If
sendmsg() returns an error it will try again. However, if sendmsg() manages to
write a part of the data then g_socket_send_message() will not try to write the
rest. It will simply return the number of bytes written. Thus the handling of
partial writes in the while loop.

Unfortunately I discovered that while handling partial writes the new function
changes the GOutputVectors that it gets as in-parameter. This may lead to weird
behavior if the caller e.g. needs to de-allocate the data chunks.

One possible solution for this is to modify the function to reset
vecs[i]->buffer and vecs[i]->size after it has handled a partial write. But I
think that is kind of ugly, because it means that although the caller still has
the ownership of the data, it is not allowed to use it while the call to the
function is ongoing. Also the code in the while loop becomes slightly more
complicated.

Another is to say that the function takes ownership of the GOutputVector array,
and thus can do whatever it wants with it. The GOutputVecor array that is, not
the actual data it points to. I think this is a clearer approach.

Which approach do you prefer, if any?

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