[MPlayer-dev-eng] PATCH: signal handling in gmplayer, immediate mode in tvi_v4l, wrong warning for tv:// MRLs

Michael Joosten joost at c-lab.de
Tue May 20 13:15:18 CEST 2003


Sergey Pinaev wrote:

> A> the options are:
> A> - clean exit from sighandler (a bit ugly), this is done now
> A> (not thread safe, but who cares, mplayer is not multithreaded)
> A> - do nothing (let the OS kill the app, without clean exit)
> A> - longjmp() hack, to jump out from a sighandler (risky, hardly
> A> portable)
> 
> "good" way should be to set signal handler with sigaction() and
> set sa_mask to block all signals during handler excution and
> replace mp_msg's in exit_sighandler with printf("we are dead\n").
> exit_player() should also be replaced with exit()...
> 

Perhaps one should differentiate between the 'ugly' signals and 
the external signals. Just 'exit()ing' is somewhat dangerous for 
stuff like tvi_v4l (tuner cards with external audio cable), 
because you want to switch/restore some stuff into the original 
state before mplayer vanishes in the bit dust, like switching 
'line audio in' off....

I haven't tried to kill mplayer with -vo fb or sdl or some other 
'direct' access mode, so I don't know what happens here; how much 
cleanup is necessary and so on.

Is printf() really signal clean? Isn't it just a wrapper like 
fprintf(stdout,...) with line buffering instead?

'Really' signal clean stuff should rather use plain write()s, I 
think. (10 years ago this was the case...)

> 
>>>btw, in mencoder you forgot to declare volatile "at_eof" and
>>>"interrupted".
> 
> 
> A> why should i do so?
> 
>    * If your handler needs to access any global variables from your
>      program, declare those variables `volatile'.  This tells the
>      compiler that the value of the variable might change
>      asynchronously, and inhibits certain optimizations that would be
>      invalidated by such modifications.
> 

Flow analysis cannot see how/when the handler is called, and 
therefore the optimizer is able to to some drastic simplifications 
to the code accessing such variables, unless you decalre them as 
volatile.

(Sergey: Thanks for the comment about the 2.5k lines... 8-))

Kind regards, Michael



More information about the MPlayer-dev-eng mailing list