Yes, I will need to implement some style rules!

Here's the current status of the old concurrency primitives:

ByteSpinLock and SpinLock: removed. 

Mutex and ThreadCondition: still in place because we have some code in older 
Safaris that expects these. I think we can remove ThreadCondition at this 
point, but Mutex needs to stay. Either way we should just move it out of 
ThreadingPrimitives and into mac/DeprecatedSymbolsUsedBySafari. 

std::mutex and friends: can't be removed, and are used by WordLock and 
ParkingLot internally as the fallback for making threads block. So, these will 
need style rules advising that you should avoid them. 

We should probably also put some thought into what styles of locking we should 
use now that we have more flexibility. For example, it would be pretty cheap to 
give Lock the ability to support assertHeldByThisThread and recursive locking. 
We should decide if we want to use the std:: lock guards or our own. 
Condition::notifyAll benchmarks as fast as Condition::notifyOne in all but 
pathological cases so it's not obvious that we need the latter. Finally, the 
advice that you should notify after releasing a lock doesn't really apply to 
our locks so we could mandate that the lock is held when you notify, since 
that's a cheap way of enforcing that you don't have a notify race. I think it 
would be great to making locking even easier and I'm curious what others think!

-Filip

> On Aug 22, 2015, at 2:46 PM, Darin Adler <[email protected]> wrote:
> 
> Even if we remove the obsolete WTF classes, we might still want a checker 
> rule about the ones in the std namespace.
> 
> — Darin
> _______________________________________________
> webkit-dev mailing list
> [email protected]
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to