[webkit-dev] MessagePorts and garbage collection

[Drew Wilson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090506/55fcca45/attachment.html>