[ecasound] yet another signal handling update

Hi,

this is about as uninteresting change as it can get, but just as
an advance notice, the git tree now has again some changes to
ecasound signal handling. So watch out for weird behaviour when
terminating ecasound in upcoming snapshot releases.

Now this should be straighforward stuff, but for various reasons, the code
for handling signals and process exit procedure, is rather complicated
(and in many places, just ugly). Some of the reasons for this are:

   - ecasound uses threads a lot (at least 3-5 threads running in
     a typical scenario), and mixing POSIX signals and threads is
     not always straightforward (although standard stuff in modern
     systems)
   - we try to support old Linux/BSD/UNIX-derived systems (in practise
     we support both sigwait() and pause(), plus a set of alternative
     ways to block signals) -> as a result, we cannot, in all cases,
     guarantee which threads get the signals sent for the ecasound process
   - ecasound launches various helper processes from its threads (e.g.
     mpg123, lame, timidity, and others), which further complicate the
     picture (unless we manage them correctly, we may leave out zombifíed
     processes after exit)
   - users expect (at least I do), that if you kill ecasound with
     a ctrl-c/SIGINT, or SIGTERM, that it will properly clean up,
     including e.g. updating audio file headers

... now the current release code does work, but in the past we've had
many (usually subtle, and only affecting certain systems) bugs in this
area. Plus, as some downsides of the current implementation, the
termination process is a bit slow (from issueing 'ctrl-c' to being back in
shell), and too often we resort in an emergency jump (skip cleanup and
just exit).

And more than one ways to exit.. In the old, as well as in the new,
implementation, there are two ways to exit ecasound: 1) the normal path,
and 2) the emergency exit. The former covers 99.999% of cases, but the
latter needs to be there as an option as well, so that you can recover if
the cleanup process gets stuck for some reason (without having to use
SIGKILL). One of the goals for the refactoring has been to make case (2)
an even less common event, and to make sure users don't accidentally exit
with (2).

So ta-daa, here's the new code. The refactored code changes the process
only slightly, but it still brings benefits:
   - The process is even more synchronized than before. In other words
     we make extra efforts to make sure all threads have completed
     cleanly (even the watchdog), and in the correct order. The last
     parts of the exit process won't progress unless all the helper
     threads have terminated.
   - Signals are unblocked much sooner than before (but still in
     a safe way), allowing one to break the cleanup process (previously
     there were some gaps during which signal handling was delayed).
   - Exit from ctrl-c is now much faster than before (even though
     we have added new thread synchronization steps).
   - Ecasound is now much more verbose (to stderr) when it
     receives signals. And especially, if a signal is received during
     process cleanup, ecasound now emits a big "are-you-really-sure"
     warning to the user.
   - New return code ('4') has been added that indicates that process was
     terminatedwithout proper cleanup, because a signal was received.
   - The code is cleaner. A lot.
   - ecasound(1) manual page now has a section on signal handling.

So that's it. This mail is very detailed, as I intend to link to this mail
from 2.7.0 release notes (less work at release time is always a win).

Now, testing this is probably not very interesting, but if somebody still
wants to give the new code a try, it's available in the git tree, as well
as in the following snapshot:

http://ecasound.seul.org/download/snapshots/ecasound-2.7.0+dev-20090210.tar.gz

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com

_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Wed Feb 11 04:15:02 2009