Hi all,
I'm fixing some race conditions in the MessagePort code, and I want to make
sure I understand how garbage collection works for things like MessagePorts
that are access across multiple threads.
Some quick background: HTML5 MessagePorts are essentially two ends of a
message channel - messages posted to one MessagePort are raised as events on
the corresponding paired ("entangled") MessagePort. They are used for
window<->worker messaging, so each MessagePort may be run by a different
thread.
I'm simplifying the situation a bit, but in general as long as there is a
reference to one of the MessagePorts, both port objects should be treated as
"reachable" for the purposes of garbage collection. There is code in
bindings/js/JSMessagePortCustom.cpp to handle this, by invoking mark() on
the entangled port.
void JSMessagePort::mark()
{
DOMObject::mark();
...
if (MessagePortProxy* entangledPort = m_impl->entangledPort()) {
DOMObject* wrapper =
getCachedDOMObjectWrapper(*Heap::heap(this)->globalData(), entangledPort);
if (wrapper && !wrapper->marked())
* wrapper->mark();*
}
...
}
There's one wrinkle, however - it's possible (via MessagePort::clone()) to
change the linkage between the two MessagePorts ; essentially one object is
swapped out for the other which requires updating the linkage on both ends.
If this were to happen in the middle of a GC operation, that would be bad.
It looks like the JSC collection code relies on JSLock to lock the heap -
I'm guessing that I'll need to explicitly grab the JSLock whenever I'm
manipulating the linkage between the two ports, is that correct? Or is there
a different/better way to handle situations like this?
-atw
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
