Thanks for the clarification Sam. On Sun, Jul 5, 2015 at 11:34 PM, Sam Roberts <[email protected]> wrote:
> On Sun, Jul 5, 2015 at 7:53 PM, Matt <[email protected]> wrote: > > On Sun, Jul 5, 2015 at 6:12 PM, Sam Roberts <[email protected]> wrote: > >> On Mon, Jun 29, 2015 at 10:37 AM, Matt <[email protected]> wrote: > >> > You've exhausted the threadpool. Try setting the UV_THREADPOOL_SIZE > env > >> > var > >> > higher and see if you can spawn more. > >> > >> Child processes don't go through the thread pool. > >> > >> The spawn is synchronous, the IPC (if any) on stdio is async, uses > >> pipes, and goes through the epoll() event loop. > > > > > > Are you sure? I haven't gone through the Node source, but I would assume > > that the wait/waitpid calls can't be done without the thread pool. Of > course > > I could be entirely wrong about that, and the calls could just wait on > the > > closing of the fd instead. But it seemed like a logical conclusion. > > I am sure. > > That it isn't async (in a thread pool) can be observed: > > child = cp.spawn(...) > console.log(child.pid) > > prints a pid... but those two lines are sync, of course, there is no > callback, right? Well, that means that the fork() at least must have > happened synchronously, because until fork returns there is no pid. > libuv actually blocks a bit longer than just the fork, it waits for > the child to do exec, too, to guarantee the success of the exec, using > a cool trick with pipes and close-on-exec, and that part of the > process is nicely commented: > > https://github.com/libuv/libuv/blob/v1.x/src/unix/process.c#L422-L441 > > And you mention waitpid going through a thread pool, but it does not, > waitpid() doesn't block (not as called by libuv, with WNOHANG), so it > doesn't need to go through a thread pool. Also, even if it did, it > would just mean that the maximum number of child processes that could > be **waited on simultaneously** would be limited to the thread pool > size, not that the maximum number of processes would be capped at > that. > > Cheers, > Sam > > -- > http://StrongLoop.com makes it easy to develop APIs in Node, plus get > DevOps capabilities like monitoring, debugging and clustering. > > -- > Job board: http://jobs.nodejs.org/ > New group rules: > https://gist.github.com/othiym23/9886289#file-moderation-policy-md > Old group rules: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/nodejs/CACmrRmQ1rT1QLPNm9KN7xVZ9G98hEjTGGcyP3ijs5_PEF4%2B2Sg%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAPJ5V2YfquGf4C23EKy4grM%3DhX4vgt9RAbkLsOUgz1FJaXfbYQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
