[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