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 678982 - filesink: handle broken pipe
filesink: handle broken pipe
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-06-27 13:52 UTC by Nicola
Modified: 2015-07-29 14:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
handle broken pipe error (1.19 KB, patch)
2012-06-27 13:52 UTC, Nicola
needs-work Details | Review

Description Nicola 2012-06-27 13:52:24 UTC
Created attachment 217401 [details] [review]
handle broken pipe error

Please try this:

mkfifo /tmp/test.fifo

gst-launch videotestsrc ! gdppay ! filesink location=/tmp/test.fifo

gst-launch -v -m -t filesrc location=/tmp/test.fifo ! gdpdepay ! fakesink

if you stop the second pipeline the first one will exit without handle the error (broken pipe),

patch attached
Comment 1 Nicola 2012-06-27 13:58:50 UTC
probably is more useful handle sigpipe everywhere so something some a global init method would be more appropriate to handle sigpipe, so all elements will handle that signal,

Nicola
Comment 2 Wim Taymans 2012-06-27 14:01:02 UTC
you can't use signals in elements. I believe there is a write variant that allows you to catch these errors in a different way.
Comment 3 Nicola 2012-06-27 16:42:15 UTC
Hi, after some searching seems that sigpipe can be handled in several ways for network sockets, I cannot find the equivalent for file writing (write,fwrite) apart the method suggested in the patch, can you give some pointers to properly handle sigpipe in filesink?

thanks
Nicola
Comment 4 Nicola 2012-06-27 16:44:04 UTC
and please explain why is a bad idea to add:

signal(SIGPIPE, SIG_IGN);

in the gstreamer init method (something like gst_init), so all elements can benefit from this
Comment 5 Tim-Philipp Müller 2012-06-27 17:19:39 UTC
Nicola: because GStreamer is a library, and a library usually has no business messing with global process state that affects non-GStreamer threads such as application threads or other libraries.

I believe there are ways to suppress sigpipe for one particular thread though, but I'm not sure we want such code in filesink tbh.
Comment 6 Nicola 2012-06-27 18:10:23 UTC
thanks Tim, I get it now, you are suggesting to set signal(SIGPIPE, SIG_IGN) in the app that use gstreamer so all gstreamer elements used in the app automatically ignore sigpipe, 

I'll try this and if it works I think this bug should be closed as wont fix and maybe the code to ignore sigpipe should be added to gst-launch
Comment 7 Wim Taymans 2012-06-27 18:38:23 UTC
Here is something interesting:

http://krokisplace.blogspot.com.es/2010/02/suppressing-sigpipe-in-library.html
Comment 8 Nicola 2012-06-28 07:14:20 UTC
Wim, thanks for the link, very interesting

Tim, Wim, please advice if you want something that manage broken pipe inside filesink (a property?) or if it is more appropriate manage that in the app, outside gstreamer, I think other elements are affected too.

If you want something inside filesink I could try to make a patch
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2013-03-29 15:58:10 UTC
Maybe we just add something to the api-docs for it and maybe add a example to tests/examples/.
Comment 10 Sebastian Dröge (slomo) 2013-07-24 09:02:50 UTC
Just docs and an example sound enough for me, anybody still has the need for that?
Comment 11 Alexandre Franke 2015-07-29 14:46:50 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment.
Thanks!