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

101–110 of 320 posts

Re: fork() can fail

#101

Post by takeda »

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.

Re: fork() can fail

#102

Post by marcosdumay »

TheLoneWolfling wrote: post #59
arthurcolle wrote: post #49

Earlier quoted context omitted.

while(fork()) {};

while(1) {fork()}; is "better", as the version you mention will quit as soon as it is able to fork a new process.

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.

Re: fork() can fail

#103

Post by djcapelis »

AnimalMuppet wrote: post #91

Somewhat OT, but in the same neighborhood: Standard file handles are another thing you should not assume are there (though I'm not sure how to test for it programmatically). We once had a user that, for whatever reason, tweaked their Unix installations to not pass an open stderr to processes - they just got stdin and stdout (that is, file handles 0 and 1, but not 2). If you wrote to stderr anywhere in your program, i…

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 stderr but instead write to stream 2, that would potentially be a problem.

That said, if for some reason you have a program completely defying the C standard, you can test whether the streams are open (and they are explicitly defined as having to be open) using fcntl and testing for EBADF at the very beginning of the program.

Re: fork() can fail

#104

Post by FooBarWidget »

quotemstr wrote: post #35

I wish posix_spawn were ubiquitous; it's a much better process-launching interface than fork: it's naturally race-free and amenable to use in multi-threaded programs, and unlike fork(2), it plays well with turning VM overcommit off. (If overcommit is off and a large process forks, the system must assume that every COW page could be made process-private and reserve that much memory. Ouch.)

Unfortunately, posix_spawn is woefully underpowered. I can't make the child process a session leader (setsid) or process group leader (setpgrp). I can't set a working directory. Etcetera.

Re: fork() can fail

#106

Post by djcapelis »

dllthomas wrote: post #96
kelnos wrote: post #81

Earlier quoted context omitted.

Perhaps I'm misunderstanding what you're saying, but that's wrong too. With fork() you need to always test 3 cases: * -1: error * 0: success, in child * > 0: success, in parent Testing for <= 0 would cause you to think there's an error when you're really just the child process.

Or that you're the child process when really there's an error, which might go undetected longer.

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.

Re: fork() can fail

#107

Post by spc476 »

dllthomas wrote: post #100
sdegutis wrote: post #94

Earlier quoted context omitted.

How is it not true? Besides void expressions (which aren't values) the above poster's statement appears correct.

A null pointer does not need to have an all-zero representation, which mattered once on some architectures. I'm not aware of any current architecture that does it that way, but that's still what the standard says, which is to say that C does technically have a notion of null which is not necessarily identical with 0. http://c-faq.com/null/machexamp.html

But in C, a 0 in a pointer context is always considered the NULL pointer (even if the physical value of a NULL pointer isn't all zeros).

Re: fork() can fail

#108

Post by mkehrt »

AnimalMuppet wrote: post #84
zokier wrote: post #13

Who needs type safety when we got integers.

Is this just using some vague connection to ride on one of your favorite hobby horses? Or does this have a connection to the article, and I missed it?

The problem is that C and POSXIX don't (idiomatically) provide rich enough data types force checking the error condition. The fact that the error is signaled by a random integer (-1) is horrible. In a language with stronger types and richer data structures, one can have a return type that is a disjunction of {failure, parent, child}, so you can never accidentally treat a failure as a PID.

In a functional language this would look like a datatype (essentially a generalized enum), while an OO language you would use different subclasses of a common superclass.

In C you can return a tagged union and check the tag, but nothing forces you to do the check. A user of this API can just go ahead and assume the success branch of the union. Furthermore, this isn't idiomatic POSIX, so it is never done.

[edit: "subclass" -> "superclass"]

Re: fork() can fail

#109

Post by quotemstr »

FooBarWidget wrote: post #104
quotemstr wrote: post #35

I wish posix_spawn were ubiquitous; it's a much better process-launching interface than fork: it's naturally race-free and amenable to use in multi-threaded programs, and unlike fork(2), it plays well with turning VM overcommit off. (If overcommit is off and a large process forks, the system must assume that every COW page could be made process-private and reserve that much memory. Ouch.)

Unfortunately, posix_spawn is woefully underpowered. I can't make the child process a session leader (setsid) or process group leader (setpgrp). I can't set a working directory. Etcetera.

Yeah --- but at least it's fairly obvious how to add platform-specific extensions that won't conflict with future standards.

Re: fork() can fail

#110

Post by tedunangst »

dllthomas wrote: post #61
pachydermic wrote: post #56

Earlier quoted context omitted.

If you can't rely on current working directories then you have to specify any file locations absolutely? That doesn't seem like a good idea because then your code quickly turns into a hot mess if you ever have to change where stuff lives. This is such a stupid problem I run into a lot. Both alternatives (doing things with absolute paths vs doing things entirely with relative paths) seem to have a lot of downsides. Ov…

As agwa and I mentioned in sibling comments, there are the ...at() functions, which let you specify actions on paths relative to a specific directory you have a file descriptor for . This not only avoids issues like the above (failing to open the directory and then failing to check for failure will mean you're passing -1 into unlinkat, which would simply fail) but will also keep you talking about the same place if li…

Rearranging the tree above CWD isn't a problem, CWD will follow along just fine (as in, be the same directory). Also, you're assuming AT_FDCWD won't be -1, which could be reasonable but isn't guaranteed afaik.
Post reply on HN