Repository navigation
Rename ChildProcess exec and fork to something which is not entirely confusing to system developers #224
Description
Activity
Totally agreed. But personally I'm already accustomed to this naming ;-(
System programers should change their process execution model to be something sensible ;)
Only sort of J/K - the unix process model is not exactly "intuitive" IMHO. But I totally agree that the current names in ChildProcess are inappropriate.
I found it confusing, too, but any suggestion of changing should include a proposal for new names! I suspect they are what they are because no one could think of better at the time.
@sam-github Fair enough.
ChildProcess.spawn- as current; equivalent to posix fork / exec.ChildProcess.execute- as ChildProcess.exec; delegates to a POSIX shell.ChildProcess.start- As ChildProcess.execFile; delegates to a POSIX shell with a-cflag.ChildProcess.run- As ChildProcess.fork; shortcut to starting a new v8 node/iojs process.
Hm, well
- execute is just longer than exec, but might guide people away from thinking it's equivalent to
exec(2). BTW, it doesn't delegate to a POSIX shell on Windows, its cmd.exe there, which is most of the value - start: doesn't use a shell on any system, its purpose in life is not use a shell, it directly spawns the executable file. This name, start, fails to indicate that it has basically the same interface as exec/execute, in that it runs to completion and returns the output, and differs only in not having an intermediate shell.
- run: isn't any more descriptive than fork(), but at least doesn't leave people thinking it is
fork(2)equivalent
I hated the names at first, too, but at this point, I think the biggest benefit would be an introduction added to the child_process docs, summarizing the use-cases for the various functions, with particular emphasis on portability (why spawn and execFile won't work for scripts, such as node scripts, on Windows).
- execute is just longer than exec, but might guide people away from thinking it's equivalent to
The best thread is here ;-D 🎄
Agree. Looks like we need some documentation to understand all cases we have.
With @sam-github: unless we're suddenly embracing breaking API changes, fixing this with documentation is a good approach.
Is there some general principles document from the TC giving the relative priority of "not breaking" and "forward"?
+1 for documentation clarification.
A documentation fix sounds like the appropriate solution. We won't be breaking API any time soon, so we're stuck with the names.
Is a simple one-line note like done here sufficient? https://github.com/nodejs/io.js/pull/1718/files
Or should the differences be explicitly stated? (And if so, is that a requirement or merely something that would be done ideally but not strictly necessary?)
I would think that something with more content would be preferable, noting
the major differences without giving uninterested parties an unrequested
crash course in system programming. Something like:child_process.exec()is unrelated to theexec()system call in
Unix-like operating systems. This call is similar to thesystem()Unix
call in that it does not replace the existing process and uses a shell to
execute the command.and
child_process.fork()is unrelated to thefork()system call in
Unix-like operating systems. This call is similar to the "fork-exec"
technique used in Unix system programs.On Sun, May 17, 2015 at 5:27 PM, Rich Trott notifications@github.com
wrote:Is a simple one-line note like done here sufficient?
https://github.com/nodejs/io.js/pull/1718/filesOr should the differences be explicitly stated? (And if so, is that a
requirement or merely something that would be done ideally but not strictly
necessary?)—
Reply to this email directly or view it on GitHub
#224 (comment).Oded
- added a commit that references this issue
on May 20, 2015 Fixed by 86dd244
- added a commit that references this issue
on Jun 3, 2015
The ChildProcess module's
execandforkmethods sound a bit similar to the system calls of that name, but behave entirely differently. I've been bit by this a few times already.To reduce confusion and make it easier to understand what is going on, these should be renamed to something like similarly functional methods in other environements (for example
execI believe is very similar tosystem, OTOH I'm not sure what I would do withfork).Also, it would be great if IO.js will add implementation for
forkandexecsystem calls so that developers can take advantage of these powerfull primitives to create their own multi-process mechanisms.