Execute in a multiprocessing child dynamic code loaded by the parent process

[Martin Di Paola]

>
>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, if that's a possibility.
>    loader()
>    target = getattr(modules[mod], func)
>    target()
>
>ch = multiprocessing.Process(target=invoke, args=("some_module", "sayhi"))
>ch.start()
>

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.

And doing the lookup by hand sounds complex.

The thing is that the use of multiprocessing is not something required by me
(by my plugin-engine), it was a decision of the developer of a particular
plugin so I don't have any control on that.

Using multiprocessing.reduction was a practical decision: if the user
wants to call something non-pickleable, it is not my fault, it is
multiprocessing's fault.

It *would* be my fault if multiprocessing.Process fails only because I'm
loading the code dynamically.

> [...] I won't say "the" correct way, as there are other valid
>ways, but there's certainly nothing wrong with this idea.

Do you have some in mind? Or may be a project that I could read?

Thanks!
Martin