Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

fork() can fail

rachelbythebay.com

Post reply on HN
Print view View original

161–170 of 320 posts

Re: fork() can fail

#161

Post by djcapelis »

dllthomas wrote: post #140
djcapelis wrote: post #106

Earlier quoted context omitted.

Thankfully that case will never happen because you can't be a child if there was an error. :) Also the check as presumably written would never miss an error, it would just potentially assume valid return values were also errors.

"Thankfully that case will never happen because you can't be a child if there was an error. :)" Uh, no. If there is an error, there will be no child process but the parent process will think it is the child . From the fork man page, emphasis mine: "On success, the PID of the child process is returned in the parent, and 0 is returned in the child. " "Also the check as presumably written would never miss an error, it w…

Ah, I see what you mean! Sorry for the misunderstanding, I had trouble parsing your post.

Re: fork() can fail

#162

Post by azinman2 »

I see a lot of comments blaming the programmer. This is completely the wrong attitude.

Why are you treating the programmer like a machine? They're not a machine -- they're human. Regardless if they fully understand the API or not things should have have sane defaults for HUMAN FACTORS reasons.

Bugs will always exist. The fact that the Linux kernel has many bugs is just one example of a code base that has over a decade of work put into it by many people with high skill shows that bugs are inevitable.

The goal should be to assume people will do stupid things and make fatal behavior more explicit/difficult. Do we really need -1 for kill to do such behavior? How common is that anyway? It's a pretty destructive behavior, and probably should be removed from kill. The human factors approach would say if you really want that behavior then write a for loop to do over the list of pids, because it should never be within easy reach especially for such an uncommon scenario.

Apple's iOS API is similar. Try to insert a nil object into an array? Crash. Try to reload an item in a list that's past the known objects index? Crash. So instead of doing something sane like reloading the entire list, the user has a shit experience because off by one errors happen easily especially in front-end/model work [1 re: fb's persistent unread chat].

Not recognizing the human part of things leads to issues everywhere.. reminding me of this article on human factors in health care previously posted on HN [2].

Conclusion: design for humans and default to non-fatal situations.

[1] http://facebook.github.io/flux/ [2] http://www.newstatesman.com/2014/05/how-mistakes-can-save-li...

Re: fork() can fail

#163

Post by djcapelis »

__david__ wrote: post #143
djcapelis wrote: post #103

Earlier quoted context omitted.

Wow that's a really wild story, but I think it's also pretty different. fork() returning -1 is defined behavior, as is true for many functions. Whereas not having stderr open defies everything about the C standard I/O. (K&R B1, 7.5 & 7.6) Note however, that strictly speaking stderr does not have to be 2. It can be any number, but it has to be whatever the include file says it is, so if you don't specify the stream as…

> Note however, that strictly speaking stderr does not have to be 2. It Nope. On POSIX systems stderr is defined as 2: http://pubs.opengroup.org/onlinepubs/9699919799/functions/st... > The following symbolic values in define the file descriptors > that shall be associated with the C-language stdin, stdout, and stderr > when the application is started: > > STDIN_FILENO > Standard input value, stdin. Its value is 0. >…

Not quite. That is according to POSIX, but not the C standard.

stderr is defined by the C standard. POSIX is a standard followed by many of the systems that run C.

Strictly speaking, stderr does not have to be 2. It wouldn't comply with POSIX in that case, but it would still be C.

Re: fork() can fail

#164

Post by marcosdumay »

dllthomas wrote: post #142
marcosdumay wrote: post #102

Earlier quoted context omitted.

Nope, it won't quit. In failure fork returns -1, what's still true... But the forked processes will quit as soon as they are created. Thus, it won't work anyway.

Parent said as soon as it is able to fork a new process, which still isn't quite right (it's the child that quits, as you say) but not the error you seem to be responding to.

He didn't say this when I replied.

Re: fork() can fail

#165

Post by donatj »

alxnlssn wrote: post #154
knocte wrote: post #139

Earlier quoted context omitted.

Are you sure? And what if $programmer forgets to check what's in err? What would pid contain in that case? I mention this because I guess you quoted a kind of syntax that matches the one from Go. So then I'm guessing that Go would simply ignore the error in this case. However, having a proper exception mechanism, if you don't catch the problem, then it bubbles up, and the program doesn't continue with wrong data (whi…

The compile will fail if err is unused. You have to explicitly ignore it by doing like this: pid,_ = fork()

And these underscores are really easy to find. Then you just do a git blame and get your shaming on at code review time.

Re: fork() can fail

#166

Post by donatj »

knocte wrote: post #139
andrewchambers wrote: post #119

Earlier quoted context omitted.

Multiple return would be fine too. pid,err = fork()

Are you sure? And what if $programmer forgets to check what's in err? What would pid contain in that case? I mention this because I guess you quoted a kind of syntax that matches the one from Go. So then I'm guessing that Go would simply ignore the error in this case. However, having a proper exception mechanism, if you don't catch the problem, then it bubbles up, and the program doesn't continue with wrong data (whi…

Actually if you want to not handle an error, you have to do either _ = err or just go data, _ = doStuff(), both of which are very visible. You can basically scan your codebase for _'s and find all the unhanded exceptions. If you don't do something with a variable, eg I do myInt := 1 but I don't use myInt go simply refuses to compile.

Re: fork() can fail

#167

Post by aroman »

azinman2 wrote: post #162

I see a lot of comments blaming the programmer. This is completely the wrong attitude. Why are you treating the programmer like a machine? They're not a machine -- they're human. Regardless if they fully understand the API or not things should have have sane defaults for HUMAN FACTORS reasons. Bugs will always exist. The fact that the Linux kernel has many bugs is just one example of a code base that has over a decad…

In general I agree with your "don't blame the programmer" point, but I would seriously hesitate to criticize fork(). Yes, in 2014, that behavior seems uncommon and it seems like very poor design to lump such destructive behavior into an otherwise meaningless "-1"...

but remember that fork was not written in 2014. It was written forty-five years ago. I'm not saying it was a great API design decision back then, but I'm willing to bet that it seemed a lot less "wrong" at the time.

Re: fork() can fail

#168

Post by quackerhacker »

Sometimes these threads are just serendipity!

I just recently finished a multithreaded program where I found obtaining the pid [on linux: getpid()] of child processes spawn was only effective by utilizing a common pipe that was non-blocking [fcntl(pipefd[1], F_SETFL, O_NONBLOCK) ].

In other, more humorous words, as a "parent," it's great to know what your "child," is doing (or in this sense), who your child is (the actual pid), instead of just kill SIGTERM them.

Re: fork() can fail

#170

Post by Mister_Snuggles »

This reminds me of the time I was telnet'd (since SSH wasn't a thing at the time) into a remote SunOS/Solaris server. At the time my only Unix experience was with Linux.

"killall -9 httpd" gave an unhelpful error message. "killall httpd" also gave an unhelpful error message. "killall", which would give you usage instructions in Linux, killed all processes on the system. Reading this article makes me figure that killall was likely a frontend to kill(-1, ...).

That day I learned a valuable lesson about reading man pages and understanding that not all unixes are the same.

Post reply on HN