To be clear, it is the thread local "magic" that I think was the problem. The Context design seems appropriate and we could complete it by continue simplifying and use Context as much as possible instead of NetworkPameters (which is contained in the context anyway). Thus, most of what is in https://bitcoinj.github.io/contexts is probably valid. But, with the backwards compatibility trick it guess Mike failed to predict the kind of leaking of Context from one test to another test and generally unpredictable outcomes if one tries to use more Contexts.
I would suggest intermediate term changes: * Let any code take explicit Context if the code needs it. - it means deprecating Context.get/propagate. * Continue rework to use Context instead of NetworkParameters where appropriate. * Longer term is to make all dependencies depend on instances (not static globals) - as an example Threading.USER_THREAD must be deprecated so each Context need to have (creates?) their own user thread. * The goal would be to allow multiple running bitcoinj with potentially different blockchains (Context) running in the same environment. - and this also completely fixes parallel test interference. Right now, we must be clear that only one Context can exist in one JVM safely. This is true, unless Context is set in strict mode, but strict mode is still not easy to use as you must prepare and know all threads you may use with the right Context. Den tisdag 27 september 2016 kl. 16:19:11 UTC+2 skrev Andreas Schildbach: > > Indeed, I'm not too happy with this either. Which is why I simply tried > to fix bugs rather than continue with the work on Contexts for the last > bitcoinj release... (I did however move some static variables into the > context.) > > Mike once compared bitcoinj contexts to OpenGL contexts, but > interestingly OpenGL contexts are mentioned one of the bad design > decisions which were "undone" with the Vulkan API. > > Still I'm not sure how to continue here. We certainly would need a > broader discussion before decidiing to go back to parameters. Most (if > not all) of the parameter based calls are still there but I think they > were planned to be removed in future. > > > On 09/20/2016 04:59 PM, Jarl Fransson wrote: > > > > So you suggest to deprecate the use of ThreadLocal for Context? > > > > Yes. I think it was a bad choice to put more semantics on threads than > > what is there already, even if it was temporary. It is better and safer > > to be explicit. It seems to have been the goal from start to eventually > > rid this: in the docs, "Eventually this auto-magic will be deleted and > > explicit passing of Context into all classes that need it will be used > > instead." > > > > All tests that create there own context could get different context than > > they expect so that points to the problems with the design. I would also > > propose to make Context explicitly immutable, which it effectively is > now. > > > > > > > > The idea of contexts is we don't need to carry it around on lots of > > calls. Not sure if we want to go back to where we came from. Also > > afaicr > > the context refactoring isn't finished yet. > > > > I realise that. I think the change is not too hard to make as most key > > objects like Wallet, Chain etc already has either Context or > NetworkParams. > > > > I think unless we discard the use Context.propagate/get, uses of > > different Context in the same process are unsafe. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "bitcoinj" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to bitcoinj+u...@googlegroups.com <javascript:> > > <mailto:bitcoinj+u...@googlegroups.com <javascript:>>. > > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
