...
- 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
- this isn't really a feature to advertise, but is race-free and safe, at least
- 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?
- Must be cheap!
- 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
- Var counts
- maintaining these adds per-bound-var costs
- and requires bindings cleanup on termination
- if we didn't need to clean up then conveyance could just be assignment of same Frame to thread's dvals
- in a world where few vars are used dynamically, and then if so almost always so, perhaps can do away with counter?
- simple flag - has ever been dynamically bound
- 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