3 ms·
Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (commun
by H8crilA 3y ago
Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (communication via pipes/socket/some-other-stream)?
- progval 3y agoThey run in the same process and can use channels for communication. https://lwn.net/Articles/820424/ https://lwn.net/Articles/820424/
- IshKebab 3y agoIt's a less complicated version of multiprocessing because you don't have to deal with multiple processes and all the complexity that that entails. It's basically web workers / isolates for Python.
- H8crilA 3y agoIt looks more complicated. You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. And it requires more care when developing the interpreter itself. Using multiprocessing was actually pretty easy (apart from the communication primitives, which obviously suck).
- IshKebab 3y agoMultiprocessing means you need to deal with signals (which are ancient and powerful footguns), handle processes being killed, platform differences (fork vs spawn), etc. It really is a bad solution. Isolates are much much better. > You get the same cumbersome communication primitive (channels), except now native code can easily get messed up. I'm not sure what you mean by that. Native code has to be thread safe sure, but now it also can be thread safe! You can have native code that is actually properly multithreaded. A big win. > And it requires more care when developing the interpreter itself. Maybe. Not really an issue for the user though.