Hacker News Reader

Comment by olliej | Hacker News Reader

The solution here, rather than using OS-internals is for Firefox to implement spin locks themselves, which is the level that they should be thinking if they're making their own allocator. This is what webkit, chromium, etc - webkit even has a blog post: https://webkit.org/blog/6161/locking-in-webkit/

View on HN

You're confusing general purpose locks with special-purpose ones used in the memory allocator. Firefox has its own GP locks, you can find them here: https://searchfox.org/mozilla-central/search?q=&path=xpcom%2...*

However those are not suitable for use in the memory allocator, and neither are WebKit's. WebKit uses os_unfair_lock within its memory allocator:

https://github.com/WebKit/WebKit/blob/520379e30f3b2b6d4de995...

And so does Chromium:

https://source.chromium.org/chromium/chromium/src/+/main:bas...

Correct, and that isn't what this article is talking about.

This article is about an internal function in the OS that they've decided to is what they'd like to use, and that the only reason they aren't using it is because it doesn't exist in older versions of macOS, because you know, it is an implementation detail of the OS.

os_unfair_lock are a documented part of the OS API: https://developer.apple.com/documentation/os/1646466-os_unfa...

Just a note thay you're replying to the author, so I'm sure they know what it's talking about :)

I get the impression the author was a little hesitant to do any spinning in userspace.

> As an intermediate solution, I initially fell back to OSSpinLock on older systems. Later I managed to get rid of it for good by relying on os_unfair_lock plus manual spinning in user-space.

Reply on news.ycombinator.com