Closed Bug 673260 Opened 13 years ago Closed 13 years ago

HttpChannelChild::RecvAssociateApplicationCache needs to be buffered like other necko IPDL messages

Categories

(Core :: Networking: HTTP, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla9

People

(Reporter: jdm, Assigned: szu.han.chang)

Details

(Whiteboard: [good first bug][mentor=jdm])

Attachments

(1 file, 1 obsolete file)

The body of RecvAssociateApplicationCache (http://hg.mozilla.org/mozilla-central/annotate/5d1799e16fe9/netwerk/protocol/http/HttpChannelChild.cpp#l196) needs to be moved into another function (AssociateApplicationCache) which is called from a runnable, exactly the same process as the surrounding Recv* functions in that file.
Attached patch Refactoring attempt #1 (obsolete) — Splinter Review
Refactored as described, compiled with success, ran the `make xpcshell-tests` in obj/netwerk/tests as well as `make check` in obj/netwerk/tests with all tests passing.

Not sure if additional tests need to be written / run though, please advise.
Attachment #554801 - Flags: review?
Comment on attachment 554801 [details] [diff] [review]
Refactoring attempt #1

>+HttpChannelChild::RecvAssociateApplicationCache(const nsCString &groupID,
>+                                                const nsCString &clientID)
>+{
>+  if (mEventQ.ShouldEnqueue()) {
>+    mEventQ.Enqueue(new AssociateApplicationCacheEvent(this, groupID, clientID));
>+  }
>+  else {

Should be "} else {".
Attachment #554801 - Flags: review? → review?(jduell.mcbugs)
Comment on attachment 554801 [details] [diff] [review]
Refactoring attempt #1

Good stuff.

I've fixed some nits and will check in a new patch.  Here's what I changed, FYI:


>+class AssociateApplicationCacheEvent : public ChannelEvent
>+{
>+  public:
>+    AssociateApplicationCacheEvent(HttpChannelChild* child,
>+                                   const nsCString &groupID,
>+								   const nsCString &clientID)

For some reason the above line uses tabs instead of spaces--fixed and make sure it indents with other parameters.

>+    : mChild(child)
>+    , groupID(groupID)
>+    , clientID(clientID) 

minor nit:  the clientID line has an extra space at the end of the line.

>+    {}
>+
>+    void Run()
>+    {
>+      mChild->AssociateApplicationCache(groupID, clientID);
>+    }

I've been formatting these as one liners (see elsewhere in file), which is non-Mozilla-standard (and I'm not sorry!).  Might as well keep file consistent.

>+void
>+HttpChannelChild::AssociateApplicationCache(const nsCString &groupID,
>+                                            const nsCString &clientID)
>+{

Note that we don't need an AutoEventEnqueuer in this method: since we don't call into client code that might spin the event loop, we're guaranteed that regular IPDL queuing will handle serialization.

> 
>-bool
>-HttpChannelChild::RecvAssociateApplicationCache(const nsCString &groupID,
>-                                                const nsCString &clientID)
>-{

Thanks for moving this--don't know how it got stuck here in between OnStartReqEvent and RecvOnStartRequest.
Attachment #554801 - Flags: review?(jduell.mcbugs) → review+
Attached patch v2: minor fixupsSplinter Review
Attachment #554801 - Attachment is obsolete: true
Attachment #554962 - Flags: review+
Han,

Thanks for the patch!  I've checked it into the "inbound" tree at Mozilla--if there are no errors detected by the test system, it will land in mozilla-central and make it into releases as of version 9.

  http://hg.mozilla.org/integration/mozilla-inbound/rev/c7c232adc3ec
Whiteboard: [good first bug][mentor=jdm] → [good first bug][mentor=jdm][inbound]
Target Milestone: --- → mozilla9
Crap, sorry for all the formatting problems, my .vimrc settings aren't quite compatible with Mozilla's. Is there someplace I can grab a Mozilla approved .vimrc file? Or if such a place doesn't exist, where can I create one?
http://hg.mozilla.org/mozilla-central/rev/c7c232adc3ec
Assignee: nobody → szu.han.chang
Status: NEW → RESOLVED
Closed: 13 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → FIXED
Whiteboard: [good first bug][mentor=jdm][inbound] → [good first bug][mentor=jdm]
Version: unspecified → Trunk
Han: Mozilla files generally have a modeline at the top (sometimes they only have an emacs one: we sadly have more emacs users than vi-ones).

The file you modified has a modeline already:

   /* vim: set sw=2 ts=8 et tw=80 : */

Somehow you must have overridden 'et' (expandtabs).

Not a big deal!
Oh, that's super cool! Will read up more on modelines, should make things a lot easier. Thanks for the pointer!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: