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
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,
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
>> 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
>> 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
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
6 matches
Mail list logo
