After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 705308 - Changing the fd property of fdsink is not threadsafe
Changing the fd property of fdsink is not threadsafe
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-01 17:25 UTC by Will Manley
Modified: 2013-08-07 15:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch - fdsink: Make changing fd property on fdsink thread-safe (5.89 KB, patch)
2013-08-01 17:25 UTC, Will Manley
rejected Details | Review

Description Will Manley 2013-08-01 17:25:06 UTC
Created attachment 250648 [details] [review]
Patch - fdsink: Make changing fd property on fdsink thread-safe

Changing the fd property of fdsink is not threadsafe.  This means that you cannot change the fd from any thread apart from the stream thread if the stream is currently running.

I've attached a patch that adds the guarantee that when
`g_object_set("fd", x, NULL)` returns the old fd will no longer be in use and may be closed, etc.

Because a lock is being held across a call to `write` this patch may cause
setting the fd to block for longer than previously unless the fd was
opened with O_NONBLOCK.  This applies to all fds on windows as I guess it
doesn't have an implementation of g_poll.  This doesn't seem so bad as due
to the previous lack of synchronisation aroud `fd` these programs would
have been relying on undefined behaviour anyway but it doesn't make me
entirely happy.

I'll see if I can also come up with a test that exacerbates this issue.
Comment 1 Sebastian Dröge (slomo) 2013-08-07 15:47:06 UTC
This is not really a supported use case for fdsink and also not one we would want to support as it adds many new problems and questions (should it resend any streamheaders when the caps change for example?). You should be able to just use multifdsink for this or alternatively just an appsink that writes to different fds.