Woof! On Mon, Jan 24, 2011 at 3:54 PM, Douglas Hubler <[email protected]> wrote:
> I have 2 points > 1.) Why have an extra thread spinning when OS will already call your > shutdown asynchronously for you? > Well, the extra thread doesn't 'spin', it's always blocked waiting for a signal. The trick is that THIS thread (and only THIS thread) will ever be the one that is woken up to deal with the signal. Otherwise, the OS picks a thread at random, and will interrupt system calls to do it...thus everyone has to deal with system calls returning EINTR and restarting them. With a thread doing the work, and it being the only thread that has signals unblocked, the code can be simplified and made much more robust. > 2.) Why reinvent the wheel on signal handling, let's remove > sipXportLib's awaitSignal() as it adds no value? > It was added because it DOES add value, see above. This change fixed some major problems in the IMDB due to semaphor's if I recall. It is the best practice for handling signals in multi-threaded linux code. --Woof!
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
