Then, you must put the initialization (dynamically loading the modules)
into the function executed in the foreign process.
You could wrap the payload function into a class instances to achieve this.
In the foreign process, you call the instance which first performs
the initialization and then exe
Martin Di Paola wrote at 2022-3-6 20:42 +:
>>Try to use `fork` as "start method" (instead of "spawn").
>
>Yes but no. Indeed with `fork` there is no need to pickle anything. In
>particular the child process will be a copy of the parent so it will
>have all the modules loaded, including the dyna
I understand that yes, pickle.loads() imports any necessary module but
only if they can be find in sys.path (like in any "import" statement).
Dynamic code loaded from a plugin (which we presume it is *not* in
sys.path) will not be loaded.
Quick check. Run in one console the following:
import mu
> On 7 Mar 2022, at 02:33, Martin Di Paola wrote:
>
> Yes but I think that unpickle (pickle.loads()) does that plus
> importing any module needed
Are you sure that unpickle will import code? I thought it did not do that.
Barry
--
https://mail.python.org/mailman/listinfo/python-list
Yeup, that would be my first choice but the catch is that "sayhi" may
not be a function of the given module. It could be a static method of
some class or any other callable.
Ah, fair. Are you able to define it by a "path", where each step in
the path is a getattr() call?
Yes but I think th
I'm not so sure about that. The author of the plugin knows they're
writing code that will be dynamically loaded, and can therefore
expect the kind of problem they're having. It could be argued that
it's their responsibility to ensure that all the needed code is loaded
into the subprocess.
Ye
On 7/03/22 9:36 am, Martin Di Paola wrote:
It *would* be my fault if multiprocessing.Process fails only because I'm
loading the code dynamically.
I'm not so sure about that. The author of the plugin knows they're
writing code that will be dynamically loaded, and can therefore
expect the kind of
On Mon, 7 Mar 2022 at 07:37, Martin Di Paola wrote:
>
>
>
> >
> >The way you've described it, it's a hack. Allow me to slightly redescribe it.
> >
> >modules = loader()
> >objs = init(modules)
> >
> >def invoke(mod, func):
> ># I'm assuming that the loader is smart enough to not load
> >#
Try to use `fork` as "start method" (instead of "spawn").
Yes but no. Indeed with `fork` there is no need to pickle anything. In
particular the child process will be a copy of the parent so it will
have all the modules loaded, including the dynamic ones. Perfect.
The problem is that `fork` is t
The way you've described it, it's a hack. Allow me to slightly redescribe it.
modules = loader()
objs = init(modules)
def invoke(mod, func):
# I'm assuming that the loader is smart enough to not load
# a module that's already loaded. Alternatively, load just the
# module you need,
Martin Di Paola wrote at 2022-3-6 12:42 +:
>Hi everyone. I implemented time ago a small plugin engine to load code
>dynamically.
>
>So far it worked well but a few days ago an user told me that he wasn't
>able to run in parallel a piece of code in MacOS.
>
>He was using multiprocessing.Process
On Sun, 6 Mar 2022 at 23:43, Martin Di Paola wrote:
>
> Hi everyone. I implemented time ago a small plugin engine to load code
> dynamically.
>
> So far it worked well but a few days ago an user told me that he wasn't
> able to run in parallel a piece of code in MacOS.
>
> He was using multiproces
Hi everyone. I implemented time ago a small plugin engine to load code
dynamically.
So far it worked well but a few days ago an user told me that he wasn't
able to run in parallel a piece of code in MacOS.
He was using multiprocessing.Process to run the code and in MacOS, the
default start metho
13 matches
Mail list logo
