[webkit-dev] MessagePorts and garbage collection

[Drew Wilson]

OK, that's good to know (it only supports document contexts) - clearly some
work has been done to prepare for multi-thread usage (for example, the core
data structure is a thread-safe MessageQueue).

I'm quite happy to drive this design (in fact, I'm in the middle of this
now) but I would like to make sure I understand in general what the correct
approach is for managing GC-able objects that are accessed cross-thread - I
haven't been able to find any documentation (outside of the code itself).

Is the right approach to use JSLock when manipulating cross-thread linkage?
I'll write up a quick document to describe the approach I'm taking, but I'd
like to understand your concerns about deadlocks. So long as we have only a
single shared per-channel mutex, and we never grab any other locks (like
JSLock) after grabbing that mutex, we should be OK. Are there other locks
that may be grabbed behind the scenes that I should be aware of?

-atw

2009/5/6 Alexey Proskuryakov <ap at webkit.org>

>
> 06.05.2009, в 21:38, Drew Wilson написал(а):
>
>  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?
>>
>
>
> The JavaScriptCore implementation of MessagePorts only supports document
> contexts (i.e., it only works on main thread).
>
> As mentioned earlier, the first thing needed to implement MessagePorts in
> workers is a design of how they can be passed around without breaking GC. It
> is likely that taking a lock whenever atomicity is desired will cause
> deadlocks.
>
> - WBR, Alexey Proskuryakov
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090506/832774fc/attachment.html>