[FFmpeg-devel] policy on "necro-bumping" patches
gajjanag at mit.edu
Wed Sep 16 20:26:28 CEST 2015
On Wed, Sep 16, 2015 at 11:08 AM, Nicolas George <george at nsup.org> wrote:
> Le nonidi 29 fructidor, an CCXXIII, Ronald S. Bultje a écrit :
>> The shell wouldn't know the difference. It has to be an atexit() mechanism
>> in the application cleaning up after itself. This isn't specific to the
>> shell state changing - it applies more generally imo.
> There is no atexit() when a program crashes due to a signal.
> If ffmpeg crashes, it is a bug. We fix it, period.
> If you frequently deal with programs that crash, possibly due to being a
> developer, then you should configure your shell to restore the tty state. I
> have done it more than fifteen years ago and did not regret it once since; I
> am in fact dumbfounded that this is not the default behaviour, and even more
> dumbfounded that smart people make so much fuss instead of applying this
> simple solution.
This is why I ask for an example natural user script where terminal
trashing occurs. The fate trashing thing (and its fix) made sense -
fate is meant to find regressions, sometimes expressed as fatal
signals. Even in non fate scenarios, ordinary signals that are within
FFmpeg's scope and not the shell's (non fatal) go to the handler,
which will restore the tty state once it receives sufficiently many
signals. Fatal signals should be very rare for non developers, and are
bugs with FFmpeg that need to be fixed as Nicolas points out.
Michael's point applies only to users and not developers; developers
can easily change their shell configuration.
> Nicolas George
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel