Hi Denis,
We are talking about forking without exec-ing right after, so using
subprocess coroutines is mostly fine.
It's dangerous because you may:
1/ run scheduled code (callback, task, etc) twice,
2/ interfere with the parent loop from the child by mistake.
1/ you can't really know if the
Hi Yuri,
On Friday, December 9, 2016 at 11:43:49 PM UTC+1, Yury Selivanov wrote:
>
> I find forking from within a coroutine or a callback function to be quite
> dangerous. It’s usually better to pre-fork or to use the approach I
> describe above (with any kind of asynchronous IO framework, not
>
>
> >
> > Ideally, you want to stop the loop, spawn a process, resume the loop.
> >
> > that does not sound what I should be doing, but I'll test it
>
> I find forking from within a coroutine or a callback function to be quite
> dangerous. It’s usually better to pre-fork or to use the approach
> > Is that what I'm supposed to do? Or is there a better way?
>
> A better was is to never fork or spawn multiprocessing.Process from a running
> coroutine.
>
> right, so if the forking is not in a coroutine it may work?!?!
It should, because the running loop is set only when the loop is
On 9 December 2016 at 21:25, Yury Selivanov wrote:
>
> > On Dec 9, 2016, at 5:57 AM, Luca Sbardella
> wrote:
> >
> > Hi,
> >
> > I'm trying to run pulsar in multiprocessing mode (using the
> multiprocessing module to create processes rather than
> On Dec 9, 2016, at 5:57 AM, Luca Sbardella wrote:
>
> Hi,
>
> I'm trying to run pulsar in multiprocessing mode (using the multiprocessing
> module to create processes rather than asyncio subprocess).
> However, in python 3.6 I have a small problem.
> When the new