Fibre-local storage about eio HOT 7 CLOSED

Using an Atomic.t value for the uid counter doesn't seem egregious.

from eio.

I think either that or a with_context function, which replaces the internal hmap for the duration of the function (much like Cancel.sub) would be good.

Oh, yeah, that's a better idea!

Do you want to make a PR? Using hmap would probably be fine. If not, I expect I'll get around to it myself at some point.

from eio.

Yes, I agree. It probably just needs an hmap in the fiber_context, alongside the thread ID:

The main concern I have is about modular reasoning - ideally two components shouldn't be able to interact without first being introduced. e.g. in

let x = ref 0 in
let y = Foo.make x in
let z = Bar.make () in

we should be able to assume that z does not have access to x. However, if Foo.make can put x in a fiber-local variable then this doesn't hold.

I see a couple of reasonable approaches:

1. Put this API in the Private module, so people know the usual rules don't apply, or
2. Only allow setting fiber-local variables at fiber-creation time, which I think might solve it (needs more thought).

from eio.

Only allow setting fiber-local variables at fiber-creation time

I think either that or a with_context function, which replaces the internal hmap for the duration of the function (much like Cancel.sub) would be good. I guess the two are largely equivalent and can be used to implement the other!

from eio.

Using hmap would probably be fine.

I guess one thing worth mentioning here is that creating keys won't be domain/thread safe (as it just uses a non-atomic reference cell). I assume that's fine, as long as it's documented?

from eio.

Yes, for now. Might be worth checking if @dbuenzli is interested in making hmap multicore safe.

from eio.

Added in #256

from eio.