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!
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.
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.
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?
Editing operations that are undoable often meet (b) but not (a). It’s confusing
to me that editing operations want to “take ownership” of arguments. To make
editing undoable the undo machinery may have to reference these objects, but it
may also have to reference objects as well, perhaps the document or other
elements. It’s not clear to me that requesting editing by passing arguments
that specify where in the document the edit should take place means that the
function takes ownership of those arguments.
If we tell the document which is the currently active title element by calling
setTitleElement, the function meets (b) but not (a).
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.
> Con (of using PassRefPtr for every parameter that takes ownership):
> Possible accidental self-zeroing bugs.
I think the “possible” adjective here makes this sound like a smaller problem
than it is. Alexey and I have both seen multiple examples of this, particularly
in contexts like constructor initialization lists where the prp idiom does not
work well.
> Con (of abandoning PassRefPtr for function arguments entirely):
> Possible accidental freed memory access bugs.
I think the reverse of this Con is one of the stronger Pro arguments for using
PassRefPtr even more for arguments rather than my proposal to use it less.
Object lifetime mistakes are much less likely when raw pointers are kept to an
absolute minimum. I thought about this when reviewing the design of Automatic
Reference Counting. The ARC design largely eliminates raw pointers for
Objective-C objects.
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?
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?
I couldn’t quickly find other examples, but I have a vague sense that there are
some that are even more confusing.
-- Darin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
