3 ms·

Happily, rather than using non-API OS internals, Firefox could recognize that their behaviour does not match normal applications and so they might have to actua

by olliej 4y ago

Happily, rather than using non-API OS internals, Firefox could recognize that their behaviour does not match normal applications and so they might have to actually implement spin locks themselves rather than relying on a API that is designed to support more general apps. That's what the other browser engines do, including webkit and that's an actual system library on macOS and iOS.

saagarjha 4y ago
Yes but also do note that WebKit is probably among the most NIH codebase on the platform.
- olliej 4y ago
  Those reasons are largely that the things that are perf critical for a browser engine don't match anything that normal apps do. That's the same reason gecko also isn't using the system allocator, as we see here. You really don't want the rest of the OS making the performance trade offs people expect from browser engines these days.
  - ben-schaaf 4y ago
    Blink uses os_unfair_lock on macOS: https://source.chromium.org/chromium/chromium/src/+/main:base/allocator/partition_allocator/spinning_mutex.h https://source.chromium.org/chromium/chromium/src/+/main:bas.... As does WebKit: https://github.com/WebKit/WebKit/blob/4c09a48ea418ff15f65d6c1331dff25ebb4dcf02/Source/bmalloc/libpas/src/libpas/pas_lock.h https://github.com/WebKit/WebKit/blob/4c09a48ea418ff15f65d6c....
    - olliej 4y ago
      Yes. Blink and WebKit, and I suspect a bunch of other - correct - software uses os_unfair_lock. Because os_unfair_lock is public, documented, and stable API. The function this article is talking about is not API, it is part of the OS internals, presumably used to implement the standard API functions.
  - saagarjha 4y ago
    I fully agree but also want to emphasize that the people who work on this at WebKit also enjoy making their own stuff.