[omniNotify] omniNotify status update

[Robert E. Gruber]

Here is a quick status update on omniNotify.  Cameron Rochester found a
deadlock case a few weeks ago, and I have been busy trying to make sure
that not only is this case fixed, but all possible deadlock cases are
fixed.  The outcome will be a more robust omniNotify.  Here are details
on what I have been doing:

I did two kinds of code rewrites:

1. I made sure all locks are acquired using helper objects that are
placed on the stack when the lock is acquired and that unlock the object
on scope exit (when the helper object destructor is run).  This makes
sure locks are properly unlocked even when exceptions are thrown or
there are return statements out of scope, etc. 

2. I added a new debugging flag, TW_DEBUG (thread wrapper debug), which,
when set, causes lock acquistion/release info to be dumped to stderr or
to a file.  Then I wrote a Perl script that examines this dumped info
for potential deadlock scenarios.  By running with TW_DEBUG=1 with the
example that Cameron found, plus just my normal range of test cases, I
have identified a set of required fixes.

I am now working on the fixes.  Certain incoming requests will need to
grab all of the locks that they need up front, so that the lock order
that they use is one that is required to prevent deadlocks.  For
example, a proxy object in some cases will need to first grab the
channel lock, then the typemap lock, then its own lock.  This means when
it calls channel methods it needs to tell the channel 'by the way, I
already hold the channel and typemap locks', so a number of internal
APIs need to change.  

I should have something that people can try out by Tuesday or Wednesday.

I hope the delay in the release of omniNotify will be worth it.  I
didn't want to do the next major release with a known deadlock bug!
Thanks for you patience.

-- Bob