[webkit-dev] MessagePorts and garbage collection

[Maciej Stachowiak]

On May 6, 2009, at 1:53 PM, Drew Wilson wrote:

> 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?


JSLock is not the right approach. Workers have their own completely  
separate GC heap. JSLock only locks the current context group's heap.  
It will not prevent collection in other heaps.

I don't know exactly what the right approach is. Ultimately it's a  
distributed GC problem, both for our split-heap multithreading and for  
an approach that used processes for workers. And distributed GC is hard.

However, Worker itself has a similar issue, since it can be kept alive  
either from the inside or the outside reference. You could look at how  
that problem was solved.

  - Maciej


>
> -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
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090506/76fb17c0/attachment.html>