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

81–90 of 320 posts

Re: fork() can fail

#81

Post by kelnos »

yokom wrote: post #79

I don't use fork() that often, but my own paranoia is why I always test for if len(some_list) But it's just my way of covering my ass in case the laws of physics change during execution, or just in case weird bugs exist like those found in this article.

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.

Re: fork() can fail

#82

Post by cpeterso »

quotemstr wrote: post #66
spudlyo wrote: post #20

If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest "it cannot happen to me", the gods shall surely punish thee for thy arrogance. [0] [0]: http://www.lysator.liu.se/c/ten-commandments.html

Counterexample: pthread_mutex_unlock. That function returns an error code, but it cannot possibly fail in a well-formed program. Checking for an error for mutex unlock is pointless: what would you do in response?

> cannot possibly fail in a well-formed program

I think that's your answer. A mutex error return probably indicates an application bug, such as double unlock. You should probably assert or abort on "can't happen" mutex errors.

Programmers are lazy. If they take the time to document an error return value, then you should probably heed their warnings. :)

Re: fork() can fail

#83

Post by dllthomas »

epochwolf wrote: post #71
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.

In C, there is no concept of null or undefined, only 0.

That's not quite true, but not a terrible approximation.

Re: fork() can fail

#85

Post by jimm »

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.

Will it quit? A failed fork() will return -1, which is non-zero thus true in a boolean context. The while(fork()) {...} will run.

Re: fork() can fail

#87

Post by rosser »

cperciva wrote: post #16
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 usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

I'm kinda surprised that the assignment-during-test thing doesn't generate a warning in the case of a switch statement. It does in other cases (if and while do under gcc and clang, at least).

Re: fork() can fail

#88

Post by thrownaway2424 »

quotemstr wrote: post #66
spudlyo wrote: post #20

If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest "it cannot happen to me", the gods shall surely punish thee for thy arrogance. [0] [0]: http://www.lysator.liu.se/c/ten-commandments.html

Counterexample: pthread_mutex_unlock. That function returns an error code, but it cannot possibly fail in a well-formed program. Checking for an error for mutex unlock is pointless: what would you do in response?

If you ever think "this can't possibly happen" then you should go right ahead and add an assertion to that effect.

Re: fork() can fail

#89

Post by ajarmst »

Stevens and Rago, "Advanced Programming in the Unix Environment, Volume II", page 211,212.

if ((pid = fork()) < 0) err_sys("fork error"); is idiomatic in Unix.

Re: fork() can fail

#90

Post by quotemstr »

cpeterso wrote: post #82
quotemstr wrote: post #66

Earlier quoted context omitted.

Counterexample: pthread_mutex_unlock. That function returns an error code, but it cannot possibly fail in a well-formed program. Checking for an error for mutex unlock is pointless: what would you do in response?

> cannot possibly fail in a well-formed program I think that's your answer. A mutex error return probably indicates an application bug, such as double unlock. You should probably assert or abort on "can't happen" mutex errors. Programmers are lazy. If they take the time to document an error return value, then you should probably heed their warnings. :)

Indeed. I like using a VERIFY macro:

    #ifdef NDEBUG
    # define VERIFY(x) ((x), 1)
    #else
    # define VERIFY(x) assert((x))
    #endif
Then you can write

    VERIFY(pthread_mutex_unlock(&lock) == 0);
You don't need, however, to consider the possibility of your program continuing to run after pthread_mutex_unlock fails.
Post reply on HN