Olivier Mélois

Good points. I don't think anything prevents us from locking the dependency on 0.11.0. And the lack of % Provided scope is totally a mis-hap. @Quafadas, wanna have a go...

I'm not too sure what kind of impact deleting would have, which is why I elected not to do it in the first place. In the grand scheme of things...

> and it'll compile locally What I'm saying is that it won't compile locally, at least I don't think it will compile in SBT.

The protocol module should not be considered "library code", so bin breakage is okay. Assuming we went ahead, what would the set-up even look like ?

I'm not necessarily opposed to it but you'd have to propose semantics (in this issue) and implement them yourself once @kubukoz and I have agreed to it.

> additionally, maybe use ConcurrentHashMap instead of TrieMap in the JVM case. The code is already platform-specific. This change would require benchmarking against the current state. Huh, I thought we...

I think it's shaping up well, but there's still a couple things to take care of though. Good work though !

Damn, forgot about that. By any chance, is there anything that could help mitigate the issue, to help other poor souls understand that it's a no-no without spending a few...

Can you elaborate ? As of now, printing `BlockingContext.current` in a program that runs on TestControl prints the id of the WorkerThread from the outer runtime. So assuming you're suggesting...

To elaborate on the context : I came across a deadlock whilst testing code that was integrating with a Caffeine-cache. I wanted to test the TTLs, and caffeine has a...