3 ms·

I've worked with similar systems in gamedev. To be exact, we downloaded 2d images and then managed image atlases with them — so we needed to update renderers no

I've worked with similar systems in gamedev. To be exact, we downloaded 2d images and then managed image atlases with them — so we needed to update renderers not only when image they required was downloaded and included in an atlas, but also when an atlas with their image was rebuilt. To be honest, the system that we designed wasn't that dissimilar from promises. It was a dynamic collection of callbacks (using built-in C# events), not unlike then/catch delegates. I've worked on it about 10-12 years ago, exactly when JS world had discussions on what flavour of promises was the best, and it was one of the main sources of inspiration.

Animats 3y ago
There's a general pattern here: * Object wants some asset. * Asset might be in memory in a cache. If so, satisfy request from cache. * If asset is not in cache, queue up request, possibly on a priority queue that gets re-prioritized. Merge requests for same asset. * When request reaches front of queue, see if the things that wanted it still want it. Remove dead requests. Discard entire request if all requestors no longer need it. * Lock against two asset fetches for same asset being performed simultaneously. * Fetch and preprocess asset * Check again that asset is still wanted. * Deliver asset * Unlock against two asset fetches for same asset. This is almost generic, except that once level of detail becomes involved, it gets less generic.