Bug 559200 - Follow up to remove unsafe locking r=dougt

--HG--
extra : rebase_source : 97dc0338081b4347a5ff0ef91861d4337967a224

netwerk/protocol/http/HttpChannelChild.cpp

@@ -49,8 +49,6 @@
 #include "nsMimeTypes.h"
 #include "nsNetUtil.h"
 
-using mozilla::MutexAutoLock;
-
 class Callback
 {
  public:
@@ -68,7 +66,6 @@ HttpChannelChild::HttpChannelChild()
   , mState(HCC_NEW)
   , mIPCOpen(false)
   , mShouldBuffer(true)
-  , mBufferLock("mozilla.net.HttpChannelChild.mBufferLock")
 {
   LOG(("Creating HttpChannelChild @%x\n", this));
 }
@@ -156,7 +153,6 @@ HttpChannelChild::RecvOnStartRequest(const nsHttpResponseHead& responseHead,
   if (mResponseHead)
     SetCookie(mResponseHead->PeekHeader(nsHttp::Set_Cookie));
 
-  MutexAutoLock lock(mBufferLock);
   bool ret = true;
   nsCOMPtr<nsIHttpChannel> kungFuDeathGrip(this);
   for (PRUint32 i = 0; i < mBufferedCallbacks.Length(); i++) {
@@ -389,14 +385,8 @@ bool
 HttpChannelChild::BufferOrDispatch(Callback* callback)
 {
   if (mShouldBuffer) {
-    MutexAutoLock lock(mBufferLock);
-    // If we can't grab the lock immediately, that means we're currently
-    // emptying the buffer. Therefore, the following condition should now
-    // be false, and we can resume immediate message processing.
-    if (mShouldBuffer) {
       mBufferedCallbacks.AppendElement(callback);
       return true;
-    }
   }
 
   bool result = callback->Run();

netwerk/protocol/http/HttpChannelChild.h

@@ -152,7 +152,6 @@ private:
   // received until OnStartRequest completes.
   nsTArray<nsAutoPtr<Callback> > mBufferedCallbacks;
   bool mShouldBuffer;
-  mozilla::Mutex mBufferLock;
 
   bool BufferOrDispatch(Callback* callback);