[Webkit-unassigned] [Bug 35689] ResourceLoader should call cancel() on ResourceHandle after clearing its client

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35689


Joe Mason <jmason at rim.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmason at rim.com




--- Comment #17 from Joe Mason <jmason at rim.com>  2010-03-10 11:05:05 PST ---
I think the core issue here is that without this patch, a ResourceHandle's
client() can become 0 unexpectedly while a network request is still open.  For
the author of a port, it's easy to assume that a ResourceHandle will always
have a valid client(), and if this invariant isn't true it can lead to bugs in
the port.  (I'm thinking mainly about new ports here; existing ports deal with
this already either by always checking client() before using it, or having
port-specific code to always call cancel() as soon as the client becomes 0.)

So I've been assuming that if some network data comes in, and I call
resourceHandle->client()->didReceiveData(...), but the client() is null, that's
a bug in webkit.  Is this a good invariant to strive for?

However, while typing this up, I just realized that this isn't true if the
network data is being received in a different thread than the one that called
setClient - in that case, there's still a window where data can be processed
after the client is set to 0 but before the job is cleaned up.  So ports will
still need to check the client() before using it, even if webkit always does
the right thing for the single-threaded case.

Also, I do think this patch needs a test case, so I think we should withdraw
it.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.