Hacker News Reader

Comment by liuliu | Hacker News Reader

This is light on details. What's the typical way to propagate version from shared memory to each renderer process so they know it is up-to-date / stale? Wouldn't a naive implementation has thundering herd problem?

View on HN

Reading a version number from shared memory is basically free, and you already had the "thundering herd" before this fix, the herd was just issuing tons of RPCs to get the latest cookie, and now they will be checking the version in shm and then early-out skipping the RPC operation because the cookie hasn't changed.

Yep that’s pretty much it. There’s no pushing of the version from the privileged process to the renderer, only pulling. So there’s not many renderers unblocking at the same time to create any kind of herd.

They possibly store just the version number for each cookie in shared memory, whereas storing complete cookie data in shared memory would need more synchronization.

You could come up with a scheme to store each version of the cookie in an accessible part of the SHM at a fixed address, but then you have to do GC to evict the oldest versions over time without causing problems etc. So I'd bet they are still retrieving the actual cookie contents via an RPC like before.

They don't quite spell it out fully but it seems like a good guess that they use a datatype (like a 64-bit word) for the version number that can be read and written atomically, so no synchronization is needed at all and it can be very fast. So it's only if you don't have the latest version that you do a slower fetch of the updated value (that you can cache) with a mutex to make sure you don't get a partial update.

Right now it’s falling back on a mojo IPC. Next step is indeed shared memory mutex :)

Hey, one of the authors here. That’s pretty much it. That said I’m currently working in the next iteration of this which would indeed share more. That said for now it’s not super trivial because it needs a cross-platform condition variable like abstraction that works across shared memory. The pthread based one is not that bad and I’m hacking on it.

Not sure there is much of a herd, because document.cookie is only shared amongst same-site renderer processes.

Yeah. I was looking for something a little more meaty, but there are solid ways to attack this.

I like to use copy-on-write reference immutable tree storage with self-recycling/self-freeing reference counting shared memory objects. Entities can retain prior versions for as long as necessary and then pop over to new versions when they’re ready, wait free. For ultimate cache and TLB performance, some other approaches (including deliberate copies) can be useful, but I’ve found the approach to be very friendly to multi-thread and multi-process scale for a long time.

This is interesting stuff. I’m one of the author of the change and working on the next iteration. If you have an example of what you describe I’d love to have a look!

Reply on news.ycombinator.com