Emulating behavior of gst-launch -e in gst program

[Krzysztof Konopko]

Hi Ian,

Oh yes, good spot.  Originally I had an 'if' statement around each call but
knowing that this was only a proposal I wanted to keep it shorter.  You're
right, should be |=.
As the comment on the ticket states I'll try g_unix_signal_add() approach
in a spare moment and will look in glib if there's an opportunity to use
signalfd() there.

Cheers,
Kris


2013/2/12 Ian Davidson <id012c3076 at blueyonder.co.uk>

> Hi Kris,
>
> I have been looking at your code and I might be about to make a fool of
> myself - but here goes.
>
> You have coded some lines - I'll just quote 2
>   int res = 0;
>   res &= sigemptyset (&mask);
>
> It is the &= which bothers me.  Since ret starts off as zero, ANDing
> anything to that means that ret will continue to be zero. Shouldn't you
> have used |= ?
>
> Ian
>
>
> On 09/02/2013 16:45, Krzysztof Konopko wrote:
>
>> On 04/02/13 10:44, Krzysztof Konopko wrote:
>>
>>> On 02/02/13 23:39, Tim-Philipp Müller wrote:
>>>
>>>> On Sat, 2013-02-02 at 16:58 +0000, Krzysztof Konopko wrote:
>>>>
>>>>  I think that gst-launch doesn't take the best approach to signal
>>>>> handling.  Use signalfd instead [1]. An example might be useful [2].
>>>>>
>>>>> You get a file descriptor which you can watch it with g_io_add_watch()
>>>>> [3].
>>>>>
>>>> Yes, that would indeed be better. However, we'll probably have to keep
>>>> the old code for compatibility reasons anyway. Feel free to make a
>>>> patch :)
>>>>
>>>> Cheers
>>>>   -Tim
>>>>
>>>>  Oh yes, I'd like to grapple with it, although signalfd() is not
>>> directly
>>> available in all libc implementations, e. g. some uClibc versions do not
>>> provide it so need to make a syscall directly (need to roll out
>>> autotools/preprocessor machinery to cater for this).
>>>
>>> Also for SIGSEGV (and probably SIGBUS) still need to use the classic
>>> approach (these are some of which signals where originally designed for).
>>>
>>> So need to give it a bit of thinking in case of gst-launch. In user apps
>>> it seems to be of less hassle.
>>>
>>> Cheers,
>>> Kris
>>>
>>>
>>>  I gave it a go:
>> https://bugzilla.gnome.org/**show_bug.cgi?id=693481<https://bugzilla.gnome.org/show_bug.cgi?id=693481>
>>
>> Cheers,
>> Kris
>>
>>
>>  ______________________________**_________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
>>>> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>>>>
>>>>  ______________________________**_________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>>>
>>>  ______________________________**_________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>>
>>
> ______________________________**_________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.**freedesktop.org<gstreamer-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/gstreamer-**devel<http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130212/18b1c927/attachment.html>