Error formatting macro: pagetree: java.lang.NullPointerException

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Convey bindings to agent and future thread-pool threads
    • Must be cheap!
      • Means you can't pay the cost of establishing truly new bindings (copies)
    • Instead, adopt binding map of point of call wholesale, including mutable cells
      • Make adoption as simple as assignment of map to thread local
      • This means these threads truly share the bindings with the caller
      • just like nested code in the caller thread would
        • i.e. can see changes
    • But - must avoid concurrency mess
      • Give bindings the semantics of volatiles
      • and check thread identity on set! calls
        • thus only the thread creating the binding can do set!s
      • thread pool threads will see effects of set!s in launching thread
        • this isn't really a feature to advertise, but is race-free and safe, at least
          • merely a side effect of doing it fast
    • Need a way to adopt a binding set wholesale
    • Need volatile semantics on binding boxes
    • Need thread ids in binding boxes
      • new nested TBox type in Var
    • Need to check matching thread on set!
    • Build conveyance into send/send-off and future?
  • Lazy seqs + bindings
    • this is trickier, quite unlikely we can afford even binding adoption per seq step
    • perhaps another flavor of lazy-seq that does binding adoption
      • use only when you need this
      • since must establish bindings every step
        • only affordable for i/o bound logic
    • Deliver this separately from thread support
    • Ditto delay?

Issues

  • In all cases, people who don't care about or use bindings in the async/delayed work won't want to pay for the overhead of this
    • how to avoid parallel set of constructs or flags everywhere?
  • Think ahead to fork/join
    • if all of our forks are via our APIs then we can do same propagation there