On Jun 19, 2011, at 12:48 PM, Darin Adler wrote: > The arguments about abandoning PassRefPtr for arguments entirely are > attacking a straw man. We know PassRefPtr offers an important optimization > and do not want to drop that!
I posited it not as a straw man but rather as an option I myself put on the table. Seems most folks agree it is a bad one. Also, examining the pros and cons of using PassRefPtr in all the cases where we do now vs in none of the cases where we do now sheds light on the relative advantages and disadvantages of using it only in some of the cases where we do now. Note that I listed using PassRefPtr for arguments less often (but not never) as a separate option. > > On Jun 18, 2011, at 10:58 PM, Maciej Stachowiak wrote: > >> (1) Use PassRefPtr for every parameter that takes ownership. > > I still think this is the appropriate rule, and always have, but I think > “takes ownership” is not defined to my satisfaction. > >> Pro (of using PassRefPtr for every parameter that takes ownership): >> Bright-line rule; fairly clear how to apply it. > > This is where my problem comes in. I am not sure what the bright-line rule is. It's approximately "this function will put the relevant parameter in a RefPtr data member or global". The DOM is more complicated, because much of the internal refcounting is done manually instead of using RefPtrs. > Generally, in the DOM, the rule is that all reachable objects need to be kept > alive, so reference counting is used to implement reachability, which does > not match with my sense of the word ownership. Reference-counted objects have shared ownership. Every object holding a reference to any other "owns" it. We could stop using the word "ownership" and instead of "take ownership" say "take a persistent reference". > For a shared ownership model there are multiple possible definitions of > whether a function takes ownership to an object passed as an argument. Here > are some of my attempts to describe the bright line: > > a) Hands off ownership to what could possibly be the sole owner in most > code paths. > b) Keeps a reference to the object after the function completes in most > code paths. > c) Takes a reference to the object at least once in most code paths. > > d) Hands off ownership to what could possibly be the sole owner in some > code paths. > e) Keeps a reference to the object after it completes in some code paths. > f) Takes a reference to the object at least once in some code paths. > > Is the bright line rule you have in mind (b) or perhaps (e)? Or something not > listed here at all? Yes, (b) or (e). I haven't thought about whether "most code paths" or "some code paths" makes more sense, but I'm not sure there are a lot of cases in our code where it makes a difference. I don't think it makes sense to talk about a sole owner of a refcounted object. If there is a sole owner at any given time, it is at best temporary. PassRefPtr is about clearly and efficiently transferring a reference, it doesn't need it to necessarily be the sole then-existing reference. […snip…] > Similarly, some functions call out to operations that could cause the last > owner for one of their arguments to dereference the object. They are likely > to fit into category (c) or (f). In a sense the caller does have to pass > ownership of the object, because the operation can only be successfully done > if the function takes ownership to make sure the object does not disappear > while the code is working with it. My understanding is that our current rule doesn't call for taking a PassRefPtr argument in this case, but I can see how it would make sense and would add helpful type checking. > > > I tried to find the examples that bother me. Here are some DOM examples where > the term ownership seems wrong, and it’s more about reachability: > > HTMLCollection::create: Does a collection own the node it is rooted in? > MessageEvent::initMessageEvent: Does a message event own the source DOM > window? > Range::create: Does a range own the document its nodes are in and the nodes > that are used to specify the endpoints? > Storage::create: Does a storage object own its storage area? > UIEvent::create: Does an event own its abstract view? It seems to me that all of these objects become shared-owners of the respective parameter, in the sense of holding a persistent reference. Some don't literally stick it in a RefPtr but they do the moral equivalent. > > Here are some examples that are not purely DOM reachability that I find > confusing: > > Document::setTitleElement: Does a document own its title element? > FrameLoaderClient::dispatchWillSubmitForm: Does communication of a pending > form submission involve passing ownership of form state? Ditto. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
