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

201–210 of 320 posts

Re: fork() can fail

#201

Post by MichaelGG »

JD557 wrote: post #144

Is there any clean way to use an Option/Maybe monad in C (or C++)? It should be a simple way to solve problems where error codes are valid inputs of other functions. The simplest way I can think of is: struct maybe { bool isEmpty; void* value; } Although I wonder if using C++ templates, classes and operator overloading is possible to make a more practical implementation (using void* does seem like a bad idea).

The problem is solved, but consider the overhead of all this. You now need an extra byte somewhere (register, stack space, whatever) to track the tag. I would imagine that this, and lack of handy syntax, is why lower-level APIs don't offer better return values.

Re: fork() can fail

#202

Post by ygra »

dllthomas wrote: post #80
ygra wrote: post #76

Earlier quoted context omitted.

Which probably can be summarized as »global state is a really bad idea«.

I wonder if it would be worthwhile to forego the notion of a CWD for processes entirely.

You'd have to use absolute paths everywhere, but that probably doesn't hurt that much in programs or scripts. The CWD seems most useful in interactive shells, I guess. A fun thing is PowerShell on Windows where you have two CWDs, one from the process and another one from the shell which had is own VFS handling (e.g. the registry is a place that has no representation in the normal file system). Cmdlets use one of them and external commands and .NET APIs use the other. So in the latter case you always need Resolve-Path foo.bar instead of just foo.bar for things to work properly.

Re: fork() can fail

#203

Post by aiiane »

takeda wrote: post #101
mutation wrote: post #18

Just noticed that in Perl the behavior is slightly different: http://perldoc.perl.org/functions/fork.html unsuccessful fork() returns undef, effectively stopping you from kill-ing what you don't want to kill.

Similarly python throws an exception, and I bet other languages have their own behaviors, but in case of C this is the only way (or at least it is the only non complicated way to do it). When I read this article I thought it was preaching to a choir. I'm actually quite surprised people programming C don't check for errors. That's the only way the functions can provide a feedback.

Not actually true. Modifying arguments that were passed in is another. :)

Re: fork() can fail

#204

Post by tracker1 »

Mister_Snuggles wrote: post #170

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 killa…

That's funny... I almost always try "command --help" first if I'm not sure. Of course some may point out "man command" but I always find man painful, and revert to google.

Re: fork() can fail

#205

Post by jervisfm »

jgrahamc wrote: post #6

Quietly goes to check the last piece of C I wrote containing a fork(): if (daemon && !test_mode) { int pid = fork(); if (pid == -1) { fatal_error("Failed to fork"); } if (pid != 0) { write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); } Phew!

I was curious too about my own code, so I looked at the last publicly available C code I wrote with fork in it[1], and yep I checked for the error case too :)

I think this just came from being drilled in school on the importance of checking error return values. No matter how unlikely never assume that something can't happen. If it really can't you should at the very least assert on it.

[1] - https://github.com/jervisfm/W4118_HW1/blob/master/shell/shel...

Re: fork() can fail

#206

Post by dllthomas »

ygra wrote: post #202
dllthomas wrote: post #80

Earlier quoted context omitted.

I wonder if it would be worthwhile to forego the notion of a CWD for processes entirely.

You'd have to use absolute paths everywhere, but that probably doesn't hurt that much in programs or scripts. The CWD seems most useful in interactive shells, I guess. A fun thing is PowerShell on Windows where you have two CWDs, one from the process and another one from the shell which had is own VFS handling (e.g. the registry is a place that has no representation in the normal file system). Cmdlets use one of them…

You wouldn't have to use absolute paths everywhere - you could use paths relative to any file descriptor that pointed at a directory. The shell itself wouldn't seem to have any problem - it could maintain a logical CWD without assistance. Utilities would probably need some other convention - maybe fd 4 points at the directory they are to operate in at start?

In a sense, this is "still a CWD" - but the differences would be 1) you can maintain multiple at the same time, and 2) you could close it.

Re: fork() can fail

#207

Post by stingraycharles »

davvid wrote: post #187
staunch wrote: post #67

Earlier quoted context omitted.

$ mkdir /tmp/foo && cd /tmp/foo && touch bar.txt

Yes. Always chain sequential commands with &&. Always. This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1]. [1] https://github.com/mlafeldt/sharness

When writing test cases in shell, you generally just implement a die() function and execute all commands `foo || die "bar"`

Re: fork() can fail

#208

Post by nitrogen »

stingraycharles wrote: post #207
davvid wrote: post #187

Earlier quoted context omitted.

Yes. Always chain sequential commands with &&. Always. This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1]. [1] https://github.com/mlafeldt/sharness

When writing test cases in shell, you generally just implement a die() function and execute all commands `foo || die "bar"`

If you don't need to specify a custom message, you could also use "set -e" to die automatically on command failure and use "trap ... EXIT" to display some kind of failure message.

Re: fork() can fail

#209

Post by kabdib »

When I was young and really didn't understand Unix, my friend and were summer students at NBS (now NIST), and one fine afternoon we wondered what would happen if you ran fork() forever.

We didn't know, so we wrote the program and ran it.

This was on a PDP-11/45 running v6 or v7 Unix. The printing console (some DECWriter 133 something or other) started burping and spewing stuff about fork failing and other bad things, and a minute or two later one of the folks who had 'root' ran into the machine room with a panic-stricken look because the system had mostly just locked up.

"What were you DOING?" he asked / yelled.

"Uh, recursive forks, to see what would happen."

He grumbled. Only a late 70s hacker with a Unix-class beard can grumble like that, the classic Unix paternal geek attitude of "I'm happy you're using this and learning, but I wish you were smarter about things."

I think we had to hard-reset the system, and it came back with an inconsistent file system which he had to repair by hand with ncheck and icheck, because this was before the days of fsck and that's what real programmers did with slightly corrupted Unix file systems back then. Uphill both ways, in the snow, on a breakfast of gravel and no documentation.

Total downtime, maybe half an hour. We were told nicely not to do that again. I think I was handed one of the illicit copies of Lions Notes a few days later. "Read that," and that's how my introduction to the guts of operating systems began.

Re: fork() can fail

#210

Post by nitrogen »

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…

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

It's a lot safer to fail fast and fail safe than to hobble along with possibly undefined state doing who knows what to the system and to the user's data.

Post reply on HN