Stas Sergeev wrote:
> Hans-Dieter Kosch wrote:
>> 1) I don't fully understand why xine_*() functions aren't signal-save.
> For many reasons. Firstly, the libc
> functions, unless listed in this table (scroll
> down to the bottom of the page):
> are signal-unsafe. I think xine-lib uses
> the rest (malloc, printf etc are unsafe,
> for instance).
Yes, they are not reentrant.
> Secondly, the xine-lib functions are itself
> signal-unsafe. The signal can arrive while
> the mutex is held (let it be a frontend_lock
> for instance), and if the mutex is not recursive
> (which is the case), it will deadlock.
> And since in the signal handler the received
> signal is masked, you have to use SIGKILL to
> get out of this.
>> 2) I wonder if there's a better way to exit from SIGINT, SIGQUIT,
>> SIGTERM than is done currently.
> I'd rather take the SIGTERM out of that list.
> If the cleanup can deadlock (or block, or became
> slow), then it is probably better for SIGTERM
> to bypass is. Otherwise you make an app which
> can be reliably killed only with SIGKILL (which
> is what xine currently is, anyway), which is not
> very good. I myself usually do not intercept
> SIGTERM at all in my programs, but other people
> may have a different opinion on this.
I think SIGTERM should yield a graceful exit like a user exit does.
>> I noticed, for example, that the audio
>> volume isn't restored upon such an exit as gui_exit() ist not called;
>> I'd like to call it, or at least important parts of it, from the
>> handler, but if the xine_*() calls therein aren't signal-save...
> The common practice here, to my knowledge, is
> to set some variable in a signal handler, but
> not do the termination sequence right away.
> Check that variable periodically in the main
> loop, and do the normal exit from there.
Good idea, but if the program has locked up, we may never reach this
> But SIGTERM is a SIGTERM, it should just terminate,
> maybe without any cleanups at all.
> of intercepting the SIGTERM is usually only that the
> user resorts to using a SIGKILL instead, and nothing
> more (go intercept SIGKILL too :)
If we could intercept that, it wouldn't earn the name SIGKILL :-)
Anyway, I've committed your patch for now, leaving elaborated signal
handling for a later time.