Re: [webkit-dev] MessagePorts and garbage collection

2009-05-07 Thread Drew Wilson
BTW, it looks like the current Worker implementation doesn't notify the Worker object when timers/network activity are finished, so an unreferenced Worker thread won't be terminated in that case. When I get done with this design mess, I'll log a bug with some tests. -atw On Thu, May 7, 2009 at

Re: [webkit-dev] MessagePorts and garbage collection

2009-05-07 Thread Maciej Stachowiak
On May 7, 2009, at 12:28 PM, Darin Adler wrote: We consider the current JavaScriptCore protected set to be something deprecated that we’d like to eliminate. We have been steadily decreasing the number of uses of it. All other things being equal, I think it would be good to keep the new

[webkit-dev] MessagePorts and garbage collection

2009-05-06 Thread 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 -

Re: [webkit-dev] MessagePorts and garbage collection

2009-05-06 Thread Alexey Proskuryakov
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

Re: [webkit-dev] MessagePorts and garbage collection

2009-05-06 Thread 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

Re: [webkit-dev] MessagePorts and garbage collection

2009-05-06 Thread 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

Re: [webkit-dev] MessagePorts and garbage collection

2009-05-06 Thread Drew Wilson
Thanks, this puts me on the right track. I've had a bunch of discussions with the Chrome folks on how we'd track MessagePort reachability in Chrome, but I'd hoped that the problem might be simpler in WebKit since we had direct access to the data structures cross-thread. The existence of separate

Re: [webkit-dev] MessagePorts and garbage collection

2009-05-06 Thread Drew Wilson
Following up. I think I have my head around how Worker GC is happening (I may start another thread about that, as it looks like there's some cases where the thread won't be shut down, but the general design is sound). MessagePort GC is a little trickier, because we need to detect when both sides