[FFmpeg-devel] [PATCH] ffplay: Exit on ctrl-c.
Alexander Strasser
eclipse7 at gmx.net
Fri Jan 13 12:44:14 CET 2012
Hi Reimar,
Reimar Döffinger wrote:
> On Wed, Jan 11, 2012 at 10:29:32PM +0100, Alexander Strasser wrote:
> > yann.lepetitcorps at free.fr wrote:
> > > Selon Alexander Strasser <eclipse7 at gmx.net>:
> > > In this case, we can perhaps use something like this ?
> > >
> > >
> > > static void signal_handler(int sig)
> > > {
> > > switch(sig)
> > > [
> > > case SIGTERM :
> > > case SIGKILL : exit(123); break;
> > > ...
> > > case SIGINT :
> > > default : force_exit = 0; break;
> > > }
> > > }
> >
> > I am sorry this is still messed up. I also don't think that
> > approach will give any practical improvements while introducing
> > more complexity. I am fine with the current solution, Micheal's
> > initial patch, as is ffplay maintainer Marton.
> >
> > Just wanted to hear any opinions on the rather theoretical issue,
> > so thanks for taking part in the discussion.
>
> The only option I see is the approach MPlayer uses:
> First just set a flag, but if more signals come in go over to more
> desperate means, if necessary even a direct exit().
> As for signal-safety: "man 7 signal" list signal-safe functions,
> so to avoid exit while staying portable FFmpeg could e.g. send
> a SIGKILL to itself.
that is interesting. I see the `signal' function is in the list
of signal-safe functions. So your idea of sending SIGKILL to itself
could probably work out.
That might be a workable approach. So if someone wants to rework
signal handling. That might be a useful idea to follow.
Also just so it doesn't get forgotten, it might make sense to handle
inputs in a different thread. That might also be good for other usage
scenarios. This was the only idea I came up with initially. Though that
is far from trivial. Also it must be evaluated if it is possible and
worth it at all.
I am currently not up for any of the tasks due to a significant lack
of time.
Alexander
More information about the ffmpeg-devel
mailing list