5 ms·
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'
by liuliu 2y ago
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?
- xuhu 2y agoThey possibly store just the version number for each cookie in shared memory, whereas storing complete cookie data in shared memory would need more synchronization.
- kevingadd 2y agoYou 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.
- tedd4u 2y agoThey 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.
- OlivierLi 2y agoRight now it’s falling back on a mojo IPC. Next step is indeed shared memory mutex :)
- OlivierLi 2y agoHey, 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.
- chaboud 2y agoYeah. 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.
- OlivierLi 2y agoThis 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!
- kevingadd 2y agoReading 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.
- OlivierLi 2y agoYep 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.
- simscitizen 2y agoNot sure there is much of a herd, because document.cookie is only shared amongst same-site renderer processes.