1

A typical JVM implementation of dynamically scoped variables tends to use ThreadLocal variables.

In code that uses Futures pervasively, a thread can be used my multiple Futures. In such a setting, is it safe to use ThreadLocal based implementations?

If not, how do I emulate a dynamically scoped variable that can work with Futures? (i.e. a sort of FutureLocal variable)

missingfaktor
  • 90,905
  • 62
  • 285
  • 365
  • 1
    Could you please add a use case for such `FutureLocal` variable? – senia Nov 17 '13 at 06:22
  • @senia, consider a Play app that is internationalized for multiple regions, and the items in database are mostly locale-specific. As such the `locale` parameter (and other context) needs to be passed down from controller to lowermost layers. In absence of `FutureLocal` variable, you might use an explicit context parameter with every method in stack, but that doesn't feel very clean. – missingfaktor Nov 17 '13 at 17:09
  • This guy here seems to have another use case - http://stackoverflow.com/questions/7259906/propagating-threadlocal-to-a-new-thread-fetched-from-a-executorservice. – missingfaktor Nov 17 '13 at 17:11
  • do you mean that a) some dynamic variable is set when a Future is created, b) a callback is attached to the Future, and c) when that Future is set, the callback is executed and have access to that variable? – Alexei Kaigorodov Nov 17 '13 at 17:11
  • @AlexeiKaigorodov, what I mean is when I say, `dynVar.withValue(someValue) { computations }`, all the `computations` executed in the block should see the herein set value of `dynVar`. The variable will be accessed by multiple futures at the same time, but each will only observe its "local" value. – missingfaktor Nov 17 '13 at 17:21
  • @missingfaktor: I can't understand your use case. Isn't this enough: `{ val someValue = getUniqueValue; future { }}`? Only single `future` has access to each `someValue`. – senia Nov 17 '13 at 20:24
  • @missingfaktor what do you mean with "variable will be accessed by multiple futures"? Variable can be accessed by a method, but future is like a special kind of variable rather than a method and cannot access variables itself. – Alexei Kaigorodov Nov 18 '13 at 06:58
  • @AlexeiKaigorodov, I want something analogous to http://www.scala-lang.org/api/current/index.html#scala.util.DynamicVariable, but for futures. – missingfaktor Nov 18 '13 at 08:50
  • @missingfaktor - "but for futures" - what does it mean? Futures do not access variables. – Alexei Kaigorodov Nov 18 '13 at 13:21
  • @AlexeiKaigorodov, it would be a "global" reference, and multiple futures, concurrently, can call `get` on it, and each should see a different value (whatever was set in its context). If still unclear, I don't know how else to explain. :( – missingfaktor Nov 18 '13 at 13:31
  • @missingfaktor "and multiple futures, concurrently, can call get on it" - only methods can call get or any other method, futures cannot call anything. – Alexei Kaigorodov Nov 18 '13 at 17:23
  • @AlexeiKaigorodov, I meant the code running in those context of futures can call `get` on that value. – missingfaktor Nov 19 '13 at 10:36
  • 1
    In a single threaded app you can, for example,..use a servlet filter to set the currently authenticated user object as `ThreadLocal`, and access it in various place in the servlet. Finally it could be removed from `ThreadLocal` when the servlet/filter is done. Using the ThreadLocal storage model breaks down in concurrently designed code (including Scala Futures), and at-least in this example would not be safe. – Nick Siderakis Nov 21 '13 at 01:40

0 Answers0