FWIW, implementing multi-phase init for a module is a relatively small task. If you are talking about full module isolation, then I suggest you break the work down into the following steps:
- implement multi-phase init
- identify process-global state (variables) in your code
- identify process-global state in external dependencies (I’m looking at you, openssl)
^^^ this one is often overlooked and I expect it will cause plenty of headaches in the future - consolidate your globals that aren’t static types, if any, into a global struct
- store that struct as module state instead of a global variable
- convert any static types to heap types (requires module state)
It’s totally worth doing, but you don’t have to do it all at once. Start with multi-phase init, which should be a trivial effort. Steps 2-4 are a good idea anyway. Steps 5 and 6 are where some projects face the most effort. There’s a nice how-to doc with helpful info. We’d definitely love feedback on pain points with any of the steps and especially about anything we can do to make the last two steps easier.
(Ironically, I created this discussion thread so we could keep my other thread focused on single-phase init vs. multi-phase init, so naturally we end up talking about that here. 
)
Good point. That we haven’t encouraged/forced the changed is probably the main reason why so many extension modules still use single-phase init (along with the perceived cost of module isolation.)
FWIW, we work fairly hard to avoid giving extension maintainers extra work. That’s part of why we haven’t pushed multi-phase init and module isolation very hard.