search

oakes / odoyle-rum-todo

7 stars 1 forks source link

question on use of volatile. #4

Closed drewverlee closed 2 years ago

drewverlee commented 2 years ago

Could you walk me through a bit more about why you used a volatile here? https://github.com/oakes/odoyle-rum-todo/blob/cb50963b4ce80aa7c4b03ffbcbf6df18dfb74fd0/src/odoyle_rum_todo/start.clj#L21

As i currently understand it, the volatile is mutable state created in each jetty thread. This has the nice advantage that jetty now handles the memory management around that memory so it doesn't accumulate.

If the data were being stored in a database, this wouldn't be necessary. Or at least, if it was used, it would serve then as a cache.

Is that correct?

oakes commented 2 years ago

You can see a bit more exaplanation here: https://github.com/oakes/odoyle-rum/blob/4703408b594d3f41a65d30b03e71b0ddf82b028a/src/odoyle/rum.cljc#L13-L19

Each component defined by the ruleset macro uses a local atom to react to the match -- i.e. it's the thing that causes the component to re-render when the rules fire. This is fine for clojurescript but when you're doing server-side rendering, this local atom would be a problem because you could be firing rules from different threads. Those threads could overwrite the local atoms in unpredictable ways. But, if the *matches* dynamic var is defined, it will instead store all matches there, which will keep it local to the thread it's defined in.

drewverlee commented 2 years ago

thanks, @oakes, that explanation makes sense to me.