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 <[email protected]> > > 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
