[webkit-dev] RFC: Improving “RefPtr inside destructor” checking

It’s a use-after-free error to create a RefPtr during ~T(), and have that RefPtr live past the end of ~T(). In debug builds, we try to catch this error by eagerly assertion !T::m_deletionHasBegun in the RefPtr constructor. At the same time, our smart pointer rules sometimes require us to use Re

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

Got it. Seems like, in this case, this is the best (i.e. only) way to do things. For the general case, I’m not sure what the current “no new language” policy states, but I would favor some kind of amendment that said “…unless it’s the only way to do things because you’re calling out to something

Re: [webkit-dev] Use of Swift (for bridging) in the WebKit project

In this specific case What is the API we’re trying to call into? Is using Swift the only way to call into it? Is there any way to reduce the use of Swift to only the calls into it, and not the surrounding objects (which all seem to be marked @objc anyway)? Thanks, Geoff

Re: [webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

For the 100 microsecond value — our research suggests that you need a much higher value in vulnerable contexts. For the guaranteed isolated case — have you considered the use of high precision time to carry out non-Spectre timing attacks? Thanks, Geoff > On Mar 17, 2021, at 3:38 AM, Yoav Weiss

Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

>> 1. It’s not just ref counting. >> >> To make String thread-safe, you also need to address all other data >> members. That means all state in m_hashAndFlags, including the >> 8bit/16bit state. >> >> It appears that your testing strategy did not reveal this point so >> far; so, you probably nee

Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

>> Because it’s so expensive, and because we have a no regression policy for >> performance, I don’t think there’s a way to land this change in pieces. It >> has to be a mega-patch, so we can test its performance as a whole. > > Were you able to quantify anything additional about the performance

Re: [webkit-dev] Making WTF::StringImpl and WTF::AtomString thread-safe

A few thoughts here: 1. It’s not just ref counting. To make String thread-safe, you also need to address all other data members. That means all state in m_hashAndFlags, including the 8bit/16bit state. It appears that your testing strategy did not reveal this point so far; so, you probably nee