Configurable inheritance for IOLocal

[armanbilge]

A small change to IOLocal that adds an option to disable "inheritance" such that its value is not copied to child fibers. This provides semantics matching a ThreadLocal; the current IOLocal implementation is like an InheritableThreadLocal.*

* for InheritableThreadLocal "the child's value can be made an arbitrary function of the parent's". Any interest in adding this functionality to IOLocal? Actually, I would find this quite useful.

Edit/update: I implemented the full-blown inheritable via an arbitrary transformation A => A, but this has the biggest performance implications. Found some discussion at #1393 (comment)

[armanbilge]

Any performance concerns? Maybe add a happy-path for an empty local state?

[armanbilge]

Closing as it seems this has already been discussed/decided at #1393; apologies for not finding it earlier.

[armanbilge]

Sorry to close/reopen 🙃 After sleeping on this, I would like to reinstate my original proposal: distinguishing between inheritable and non-inheritable IOLocals.

In #1393 (comment) @kubukoz proposed a very general interface for IOLocal. While I agree with @djspiewak's concern whether "that kind of complexity carries its weight" (especially regarding the join stuff), it is unfortunate that the current IOLocal cannot support certain forking behaviors.

Thus, my rationale is simple: having both inheritable and non-inheritable IOLocals I believe are the minimum necessary components to support the more general fork behaviours that @kubukoz's proposal was going for.

For example, the concept of a transformation A => IO[A] upon inheritance can be implemented by an inheritable IOLocal[A] and a non-inheritable IOLocal[Boolean] flag indicating whether A has been "initialized" for that fiber.

Thanks in advance, and really hope that this can be considered.

[djspiewak]

@armanbilge Honestly, I'm not sure I've changed my views too much from what I expressed in my comment. :-) Regarding heritability specifically, note just how common it is to create and throw away fibers. Nearly every parallel-related combinator does this! Fibers are cheap, so we abuse them, and that's okay. The problem is that if you don't have inherited local state, you're going to end up in a really confusing situation where things just don't work the way you expect. Semantics swapping between tupled and parTupled is a good example of this.

I also kind of want to hold off on this kind of complexity until we're really forced (by use-cases) to take it on. This change would considerably complicate IOLocal's meaning. Would it be worth it? Maybe? We can't really say for sure yet. Let's revisit this proposal if we start seeing an influx of cases where people really need this type of behavior.