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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #18 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
> 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.

This is when the socket is in non-blocking mode, correct?

But when you set it to blocking mode, surely it will retry and loop until it
has sent out all messages? (Or there's an error)


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

Why is that? Not sure I understand the problem here. Could you explain?


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

Not sure, I don't think it should take ownership of a GOutputVector? I would
expect that a GOutputVector array is often/usually allocated by the caller on
the stack anyway? Or in a caller-owned scratch area that is reused for
subsequent calls.

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